Я хочу знать, какова именно последовательность вызовов, которая происходит при вызове получателя / сеттера, созданного с помощью Class :: MethodMaker?
Насколько дороже методы получения и установки, определенные в MethodMaker, чем собственные (перезаписанные в модуле)?





Настоящий вопрос: имеет ли это значение?
Это еще один модуль генерации аксессоров. Все эти модули имеют компромисс между скоростью и функциональностью. Просто выберите тот, который предлагает все, что вам нужно. Не похоже, что аксессоры могут стать узким местом в вашем приложении.
@ Леон Тиммерманс
Я осведомлен о том, что есть некоторая компромисс между скоростью и функциональностью, но хочу понять, насколько это хорошо / плохо? И гораздо лучше, если я смогу получить конкретную реализацию, чтобы ее было легче решить.
Именно для этого нужны инструменты отладки :)
Посмотрите документы perldebug, особенно раздел о профилировании.
В частности, запуск вашего скрипта с perl -dDProf filename.pl сгенерирует файл tt.out, из которого инструмент dprofpp (распространяемый с Perl) может создать отчет.
Я использовал следующий простой тестовый сценарий:
#!/usr/bin/perl
package Foo;
use strict;
use Class::MethodMaker [ scalar => ['bar'], new => ['new'] ];
package main;
use strict;
my $foo = new Foo;
$foo->bar('baz');
print $foo->bar . "\n";
Запуск его с помощью perl -d: DProf methodmakertest.pl, а затем использование dprofpp на выходе дало:
[davidp@supernova:~/tmp]$ dprofpp tmon.out
Class::MethodMaker::scalar::scal0000 has 1 unstacked calls in outer
Class::MethodMaker::Engine::new has 1 unstacked calls in outer
AutoLoader::AUTOLOAD has -2 unstacked calls in outer
Total Elapsed Time = 0.08894 Seconds
User+System Time = 0.07894 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
25.3 0.020 0.020 4 0.0050 0.0050 Class::MethodMaker::Constants::BEG
IN
25.3 0.020 0.029 12 0.0017 0.0025 Class::MethodMaker::Engine::BEGIN
12.6 0.010 0.010 1 0.0100 0.0100 DynaLoader::dl_load_file
12.6 0.010 0.010 2 0.0050 0.0050 AutoLoader::AUTOLOAD
12.6 0.010 0.010 14 0.0007 0.0007 Class::MethodMaker::V1Compat::reph
rase_prefix_option
0.00 0.000 0.000 1 0.0000 0.0000 Class::MethodMaker::scalar::scal00
00
0.00 0.000 0.000 1 0.0000 0.0000 Class::MethodMaker::Engine::new
0.00 - -0.000 1 - - DynaLoader::dl_undef_symbols
0.00 - -0.000 1 - - Class::MethodMaker::bootstrap
0.00 - -0.000 1 - - warnings::BEGIN
0.00 - -0.000 1 - - warnings::unimport
0.00 - -0.000 1 - - DynaLoader::dl_find_symbol
0.00 - -0.000 1 - - DynaLoader::dl_install_xsub
0.00 - -0.000 1 - - UNIVERSAL::VERSION
0.00 - -0.000 1 - - Foo::new
Два самых дорогих вызова - это блоки Class :: MethodMaker :: Constants :: BEGIN и Class :: MethodMaker :: Engine :: BEGIN, которые, очевидно, вызываются только во время компиляции, поэтому они могут немного замедлить компиляцию вашего скрипта, но это не влияет на последующее создание объекта / использование средства доступа.
В дополнение к моему предыдущему ответу, если вы хотите точно увидеть, что происходит под капотом в деталях, запустите свой сценарий в отладчике с включенным режимом трассировки (perl -d filename.pl, затем скажите «t» для трассировки, затем «r "для запуска сценария; однако ожидайте много вывода!).
У меня нет простого ответа на ваш вопрос относительно производительности Class :: MethodMaker. Как упоминалось в предыдущем ответе, вы можете использовать отладчик, чтобы узнать, что происходит под капотом. Однако я знаю, что Class :: MethodMaker генерирует количество кода огромный во время установки. Это укажет мне на три отдельные вещи:
Вам действительно нужно потратить несколько минут, чтобы подумать о том, что вам действительно нужно. Если вы хотите, чтобы простые методы доступа были автоматически сгенерированы, но написали что-то более сложное вручную, возможно, посмотрите Class :: Accessor :: Fast. Или, если вам нужны самые быстрые из возможных методов доступа, изучите Class :: XSAccessor, сверхпростые методы которого работают как код C / XS и примерно в два раза быстрее, чем самый быстрый метод доступа Perl. (Примечание: я написал последний модуль, так что относитесь к нему с недоверием.)
Еще один комментарий: если вы когда-нибудь собираетесь использовать набор инструментов PAR / PAR :: Packer для упаковки своего приложения, обратите внимание, что большой объем кода Class :: MethodMaker приводит к значительно большему исполняемому файлу и более медленному начальному запуску. время. Кроме того, существует известная несовместимость между C :: MethodMaker и PAR. Но это можно считать ошибкой PAR.