Fri, 16 Jan 2015 15:14:36 +0100 от PEF Secure <[email protected]>: >On Friday, January 16, 2015 16:44:56 [email protected] wrote: >> Ладно, вот вам тест: >> > http://pastebin.ru/Un6reVrU > >for(my $i = 1; $i < $iterations; $i++){ > eval "package Namespace2::${i};\nsub cool_long_method { my \$self = shift; >print \"This method is loooong\\n\";} 1;"; >} > >Я чувствую, что либо меня не понять, либо Вы не поняли. > >_Зачем_ делать миллион итераций с eval? Это какая то совсем иная проблема. Я >измерял следующий вариант: > >eval {"\$sub_eval = sub {my \$self = shift; print \"This method is >loooong\\n\";}" }; > >в сравнении с: > >$sub_pure = sub {my $self = shift; print "This method is loooong\n" }; > >и сравнивал соответственно быстродействие $sub_eval->() и $sub_pure->(). >Разницы почти нет. > >Именно этого случая я пытаюсь добиваться, а не того, что Вы написали. Только у >вас, насколько я помню именно генерация модуля идет, так? Если да, то вы не то >и не с тем сравниваете... давайте на простом примере, ладно... http://pastebin.ru/huvowqZG Специально для вас - комментарии... Мы симулируем что у нас в базе 100.000 таблиц, чтобы было нагляднее. В случае с ISA - создаем новый пакет, где весь код прописан в базовом и настраиваем свойства конкретно пакета (минимизируем часть, которая свойственна генерирующемуся пакету в пользу статического пакета с базовыми методами). В случае с eval тупо создаем кучу пакетов с кастомным кодом. Я намеренно не делаю парсинг данных тут, так как у вас в методе data нету ни одного подстановочного места и он будет работать одинаково для обоих случаев.с остальными будет ак, как с методом query тут. Я намеренно не использую XS аксессоры, которые быстрее, чтобы не код был более читабелен и тут не было никакой XS'ной магии. Теперь по скорости работы... Вариант с ISA в 2 раза медленней, так как реально тестируется вызов сабы 1 раз или 2 раза. Это самый плохой вариант для меня, так как нету обвязки рядом. Как только вы накручиваете логику цифры будут приблежаться одна к другой. Причем это вызов метода класса, если вызывать на объекте и с XS магией, то eval вариант будет на 20% быстрее, а ISA на 40 (от текущих) Фактически вы выжимаете где-то 30%-50% скорости, но делаете этот код не расширяемым и не поддерживаемым никем, кроме вас. Такие модули на цпане никому не нужны. При этом вы теряете скорость на старте и память на создании кучи пакетов с одинаковым кодом. > > >> Так вы для себя или выложить на >> >cpan? Если для себя - ок. Если на cpan - это проблема. > >Для себя я б тут даже выступать не стал. Сидел бы себе и писал что хотел. > >> >А еще большая >> >проблема, если у вас перед Pg стоит PgBouncer в режиме >> >TRANSACTION_POOLING.> > >В чём именно проблема? > > >>На примере выше. Я могу сделать так: Base::cool_long_method = sub { ... } , >>будет перехвачено все. В вашем случае, даже с наследованием - не будет >>перехвачено ничего. Чтобы это сработало, надо сделать класс наследник, куда >>запихать сначала меня, потом то что вы нагенерили (По определению работы >>наследования). то есть: > >Раз уж нам доступна кодогенерация свыше, всегда можно сделать то, что хочется. >Например, инъекцию пользовательского кода. Я не говорю, что собираюсь это >сделать, я говорю, что это _можно_. Я не пытаюсь из данных, выбранных из БД >сделать полноценный произвольный объект в смысле ООП. Я использую их именно >как данные, а абстракции у меня в другом слое. > >> >Нет, на классе. Название таблицы и прочего засовывается в класс аксессор, >> >а не в объект. И оверхеда копейки. Вы больше своим евалом генерите.> > >Название модуля (класса), к которому объект, (в дебрях не копался, но из общих >соображений) должно быть одним указателем на описание этого модуля, единое для >всех объектов (экземпляров). 8 байт на 64 бит платформе. Что-то мне кажется, >Вы уже поплыли... > > >> Это вредное свойство. Наглядный пример - выше. > >Который я не понял как относится к _моему_ коду. > >> А вы написали что он внутренний? А то у вас >> >внутренние с _ начинаются, а этот - нет... Значит не внутренний. > >Да, упустил. Спасибо за багрепорт. >-- >PEF Developer >-- >Moscow.pm mailing list >[email protected] | http://moscow.pm.org
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
