<HTML><BODY><br><br><br>Fri, 16 Jan 2015 15:14:36 +0100 от PEF Secure <pef-secure@yandex.ru>:<br>
<blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14214177010000000641_BODY">On Friday, January 16, 2015 16:44:56 <a href="/compose?To=Warstone@list.ru">Warstone@list.ru</a> wrote:<br>
> Ладно, вот вам тест: <br>
> ><a href="http://pastebin.ru/Un6reVrU" target="_blank">http://pastebin.ru/Un6reVrU</a><br><br>
for(my $i = 1; $i < $iterations; $i++){<br>
eval "package Namespace2::${i};\nsub cool_long_method { my \$self = shift; <br>
print \"This method is loooong\\n\";} 1;";<br>
}<br><br>
Я чувствую, что либо меня не понять, либо Вы не поняли.<br><br>
_Зачем_ делать миллион итераций с eval? Это какая то совсем иная проблема. Я <br>
измерял следующий вариант:<br><br>
eval {"\$sub_eval = sub {my \$self = shift; print \"This method is <br>
loooong\\n\";}" }; <br><br>
в сравнении с:<br><br>
$sub_pure = sub {my $self = shift; print "This method is loooong\n" };<br><br>
и сравнивал соответственно быстродействие $sub_eval->() и $sub_pure->(). <br>
Разницы почти нет. <br><br>
Именно этого случая я пытаюсь добиваться, а не того, что Вы написали.</div></div></div></div></blockquote>Только у вас, насколько я помню именно генерация модуля идет, так? Если да, то вы не то и не с тем сравниваете... давайте на простом примере, ладно...<br>http://pastebin.ru/huvowqZG<br>Специально для вас - комментарии... Мы симулируем что у нас в базе 100.000 таблиц, чтобы было нагляднее.<br>В случае с ISA - создаем новый пакет, где весь код прописан в базовом и настраиваем свойства конкретно пакета (минимизируем часть, которая свойственна генерирующемуся пакету в пользу статического пакета с базовыми методами).<br>В случае с eval тупо создаем кучу пакетов с кастомным кодом. Я намеренно не делаю парсинг данных тут, так как у вас в методе data нету ни одного подстановочного места и он будет работать одинаково для обоих случаев.с остальными будет ак, как с методом query тут.<br><br>Я намеренно не использую XS аксессоры, которые быстрее, чтобы не код был более читабелен и тут не было никакой XS'ной магии.<br><br>Теперь по скорости работы... Вариант с ISA в 2 раза медленней, так как реально тестируется вызов сабы 1 раз или 2 раза. Это самый плохой вариант для меня, так как нету обвязки рядом. Как только вы накручиваете логику цифры будут приблежаться одна к другой. Причем это вызов метода класса, если вызывать на объекте и с XS магией, то eval вариант будет на 20% быстрее, а ISA на 40 (от текущих)<br><br>Фактически вы выжимаете где-то 30%-50% скорости, но делаете этот код не расширяемым и не поддерживаемым никем, кроме вас. Такие модули на цпане никому не нужны. При этом вы теряете скорость на старте и память на создании кучи пакетов с одинаковым кодом.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14214177010000000641_BODY"><br><br>
> Так вы для себя или выложить на<br>
> >cpan? Если для себя - ок. Если на cpan - это проблема. <br><br>
Для себя я б тут даже выступать не стал. Сидел бы себе и писал что хотел. <br><br>
> >А еще большая<br>
> >проблема, если у вас перед Pg стоит PgBouncer в режиме<br>
> >TRANSACTION_POOLING.><br><br>
В чём именно проблема?<br><br><br>
>На примере выше. Я могу сделать так: Base::cool_long_method = sub { ... } ,<br>
>будет перехвачено все. В вашем случае, даже с наследованием - не будет<br>
>перехвачено ничего. Чтобы это сработало, надо сделать класс наследник, куда<br>
>запихать сначала меня, потом то что вы нагенерили (По определению работы<br>
>наследования). то есть:<br><br>
Раз уж нам доступна кодогенерация свыше, всегда можно сделать то, что хочется. <br>
Например, инъекцию пользовательского кода. Я не говорю, что собираюсь это <br>
сделать, я говорю, что это _можно_. Я не пытаюсь из данных, выбранных из БД <br>
сделать полноценный произвольный объект в смысле ООП. Я использую их именно <br>
как данные, а абстракции у меня в другом слое.<br><br>
> >Нет, на классе. Название таблицы и прочего засовывается в класс аксессор,<br>
> >а не в объект. И оверхеда копейки. Вы больше своим евалом генерите.><br><br>
Название модуля (класса), к которому объект, (в дебрях не копался, но из общих <br>
соображений) должно быть одним указателем на описание этого модуля, единое для <br>
всех объектов (экземпляров). 8 байт на 64 бит платформе. Что-то мне кажется, <br>
Вы уже поплыли...<br><br><br>
> Это вредное свойство. Наглядный пример - выше.<br><br>
Который я не понял как относится к _моему_ коду. <br><br>
> А вы написали что он внутренний? А то у вас<br>
> >внутренние с _ начинаются, а этот - нет... Значит не внутренний.<br><br>
Да, упустил. Спасибо за багрепорт.<br>
-- <br>
PEF Developer<br>
-- <br>
Moscow.pm mailing list<br><a href="/compose?To=moscow%2dpm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br></div></div></div></div></blockquote>
<br></BODY></HTML>