<HTML><BODY><br>Fri, 16 Jan 2015 13:40:49 +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_14214120720000000403_BODY">On Friday, January 16, 2015 14:45:17 <a href="/compose?To=Warstone@list.ru">Warstone@list.ru</a> wrote:<br>
> Я, наверно, последний раз напишу, так как далее бессмысленно, очевидно...<br><br>
Поскольку ж написали, мне придётся ответить :)<br><br>
> 4. На то, сколько программа будет занимать в памяти после того,<br>
> >как вы все нагенерите.<br><br>
Ну сгенерируется и скомпилируется код на каждый _класс_. Он и так и этак бы <br>
компилировался, что при ORM, что с моим модулем. Речь может идти только о <br>
"производных" классах, которые основаны на генерящихся запросах, тут всё от <br>
приложения зависит, но мне сомнительно, что это такая уж проблема.</div></div></div></div></blockquote>Вы принципиально издеваетесь?... Ладно, вот вам тест: <a href="http://pastebin.ru/Un6reVrU">http://pastebin.ru/Un6reVrU</a><br>Быстрее в 6 раз, памяти занимает более чем в 2 раза меньше. И это при том, что тут один метод с очень маленьким кодом. при увеличении кода разрыв будет увеличиваться, так как в обоих случаях много на себя берет сам стеш и "создание" модуля. Вывод:<br>_Пуш в ису гораздо быстрее по времени, меньше занимает памяти и вообще лучше чем кодогенерация. Всегда_ Забудьте про кодогенерацию. Если вы ее используете вы что-то делаете не так.<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_14214120720000000403_BODY">> >Хотя ладно, это придирка. Могу еще одну<br>
> >рассказать... Вы пользуете DBIx::Connector, который в себе при создании<br>
> >имеет следующее: $self->{pid} = $$; Прощай форк после вашего populate'а.<br><br>
Почему же? Стартап: connect, populate. Дальше форки могут идти сколько угодно, <br>
их кухню от меня скроет DBIx::Connector. Если речь о prepared, то их <br>
использования пока нет, и "прозрачный реконнект" как одна из причин. Хотя уже <br>
давно думаю над их внедрением. </div></div></div></div></blockquote>Так вы для себя или выложить на cpan? Если для себя - ок. Если на cpan - это проблема. А еще большая проблема, если у вас перед Pg стоит PgBouncer в режиме TRANSACTION_POOLING.<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_14214120720000000403_BODY">> Сделать "просто". Если мне не допустим надо сделать аудит в моем<br>
> >варианте я перебиваю базовые методы в Base пакете. В вашем мне надо по<br>
> >всей схеме пройтись. Это для примера.<br><br>
Слишком абстрактно. Но идею я понял. Как вариант, могу сделать настройку, <br>
чтобы все генерируемые классы наследовали какой-то, который будет указан. Если <br>
я правильно понял вопрос.</div></div></div></div></blockquote>На примере выше. Я могу сделать так: Base::cool_long_method = sub { ... } , будет перехвачено все. В вашем случае, даже с наследованием - не будет перехвачено ничего. Чтобы это сработало, надо сделать класс наследник, куда запихать сначала меня, потом то что вы нагенерили (По определению работы наследования). то есть:<br>package Schema::Table;<br>our @ISA = qw/Schema::Table::Base/;<br>тогда можно через сплайс вставить себя перед вами и получить то, что я получаю простым присвоением. и делать это надо каждый раз.<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_14214120720000000403_BODY">> Ну куда вы полезли?.. Доступ к хешу в классе. Вы экономите чуть-чуть на<br>
> кждом созданном классе таким образом, а не объекте.<br><br>
Зависит от меры "чуть-чуть". В два раза минимум, ведь как минимум массиву не <br>
нужно хранить названия ключей для каждой строки, их знание обозначено один раз <br>
в описании класса. Экономлю именно на каждом созданном объекте. Убедиться в <br>
разнице memory footprint можно используя модуль Devel::Size.</div></div></div></div></blockquote>Нет, на классе. Название таблицы и прочего засовывается в класс аксессор, а не в объект. И оверхеда копейки. Вы больше своим евалом генерите.<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_14214120720000000403_BODY">> >А для вас динамический - это только eval? <br><br>
Нет, но именно при написании _фреймворка_ мне это видится очень полезным <br>
свойством. До написания фреймворка пользовался им для перехвата исключений, в <br>
основном.</div></div></div></div></blockquote>Это вредное свойство. Наглядный пример - выше.<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_14214120720000000403_BODY">> Проблема вот в этом: setup_row('table1',<br>
> >'MySchema::Table'); setup_row('table2', 'MySchema::Table'). На 2-м должен<br>
> >упасть. У вас не падает.<br><br>
Там иной сценарий использования. Это внутренний метод, такого варианта, что Вы <br>
написали, в модуле нет. </div></div></div></div></blockquote>А вы написали что он внутренний? А то у вас внутренние с _ начинаются, а этот - нет... Значит не внутренний.<br><br></BODY></HTML>