What does Class::MethodMaker exactly do?

Question

I want to know what exactly is the sequence of calls when a getter/setter created through Class::MethodMaker is called?

How costlier are getter/setters defined by MethodMaker than the native ones(overwritten in the module)?

Answer 1

The real question is: does it matter?

It's yet another accessors generating module. These modules all have a speed/functionality trade-off. Just pick one that offers everything you need. It's not like accessors are likely to become a bottleneck in your application.

Answer 2

@Leon Timmermans

I am aware of the fact that there is some speed/functionality trade off but want to get idea of how good/bad is it? And much better, if I can get specific of the implementations so that its easier to decide.

Answer 3

This is exactly what debugging tools are for :)

Have a look at the perldebug docs, particularly the section on profiling.

In particular, running your script with perl -dDProf filename.pl will generate a tt.out file which the dprofpp tool (distributed with Perl) can produce a report from.

I used the following simple test script:

#!/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";

Running it with perl -d:DProf methodmakertest.pl and then using dprofpp on the output gave:

[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

The two most expensive calls are the Class::MethodMaker::Constants::BEGIN and Class::MethodMaker::Engine::BEGIN blocks, which are obviously called at compile time only, so they may slow the compilation of your script slightly, but subsequent object creation/accessor usage is not affected by it.

Answer 4

Further to my previous answer, if you want to see exactly what's going on under the hood in detail, run your script in the debugger with trace mode on (perl -d filename.pl, then say "t" to trace, then "r" to run the script; expect a lot of output though!).

Answer 5

I don't have a simple answer for your question regarding Class::MethodMaker performance. As a previous answer mentioned, you can use the debugger to find out what's going on under the hood. However, I know that Class::MethodMaker generates huge amounts of code at install time. This would indicate three separate things to me:

1. Regarding run-time, it's probably on the faster side of the whole slew of method generators. Why generate loads of code at install time otherwise?
2. It installs O(Megabytes) of code on your disk!
3. It may potentially be slow at compile time, depending on what parts of the generated code are loaded for simple use cases.

You really need to spend a few minutes to think about what you really need. If you want simple accessor methods auto-generated but write anything more complicated by hand, maybe look at Class::Accessor::Fast. Or, if you want the fastest possible accessor-methods, investigate Class::XSAccessor, whose extra-simple methods run as C/XS code and are approximately twice as fast as the fastest Perl accessor. (Note: I wrote the latter module, so take this with a grain of salt.)

One further comment: if you're ever going to use the PAR/PAR::Packer toolkit for packaging your application, note that the large amount of code of Class::MethodMaker results in a significantly larger executable and a slower initial start-up time. Additionally, there's a known incompatibility between C::MethodMaker and PAR. But that may be considered a PAR bug.