Fri, 16 Jan 2015 13:40:49 +0100 от PEF Secure <[email protected]>: >On Friday, January 16, 2015 14:45:17 [email protected] 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-м должен >> >упасть. У вас не падает. > >Там иной сценарий использования. Это внутренний метод, такого варианта, что Вы >написали, в модуле нет. А вы написали что он внутренний? А то у вас >внутренние с _ начинаются, а этот - нет... Значит не внутренний.
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
