[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct

[Warstone@list.ru]

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

----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/7c442489/attachment-0001.html>