how to shave 10% speed?

contributing to other projects is good (not counting the fact that it's fun):
  • you help open-source as a whole
  • you gain some knowledge on the projects you help
  • ... and you discover some new stuff, techniques, tricks
so recently i've been helping the padre team, where i discovered the module class::xsaccessor. reading the pod, it seemed quite good, but the question was: is it really that interesting?

so, i decided to try that on language::befunge, which currently uses a mix of class::accessor::fast and hand-crafted accessors (man, some part of the code is untouched since 2002!). who recalls of using the following in his/her code:
my @attrs = qw{ attr1 attr2 attr3 };
foreach my $attr ( @attrs ) {
my $code = qq[ sub get_$attr { return \$_[0]->{$attr} } ];
$code .= qq[ sub set_$attr { \$_[0]->{$attr} = \$_[1] } ];
eval $code;

anyway, i created a new git branch in langage::befunge's repository, and ported all my classes to use class::xsaccessor. and then i've run both the module's test suite and mycology:
  • current language::befunge: tests = 5.28s, mycology = 20.48s
  • using class::xsaccessor: tests = 5.12s, mycology = 18.18s
(everything ran once to warm cache, and then averaging three passes. all output directed to /dev/null in order not to pollute cpu measures with io)

that is, around 5% saved (a bit less) for the tests, but 10% (a bit more) for mycology. knowing that the tests are not representative of real befunge workload, this means a 10% speedup in befunge programs... neat!

needless to say that i merged this temp branch (ain't git cool?) to master, and language::befunge 4.09 is on its way to cpan!

conclusion: use class::xsaccessor, it fulfils its promises... and contribute to other projects, at least you'll find some ideas for your own projects!


  1. When I converted File-Find-Object from Class-Accessor to Class-XSAccessor, I got a dramatic speed increase from 2 minutes down to 1:20 minutes. Class-XSAccessor indeed provides a huge speed-up and is otherwise very recommended.

  2. It's nice to see one of my modules being recommended. But I do have to warn you about it, too:

    a) You can't step into it with the debugger (which can be considered both good or bad for accessors).

    b) It'll likely crash BADLY when you use it with tied hashes as objects. Don't misunderstand this: Storing tied object in your object is fine. But if the objects you're calling the XS methods on is tied, the magic won't be respected.

    mst cursed me for this latter issue once and maybe I'll rectify it somewhen. But it's not much of a problem since whoever adds accessors should have control over the class anyway. The real problem is that IF a problem occurs, it's likely to be SERIOUS.
    I don't know how this plays with some of the object-mocking stuff from Test:: for example.