in reply to Re: Micro optimisations can pay off, and needn't be a maintenance problem
in thread Micro optimisations can pay off, and needn't be a maintenance problem

Another idea is to have some other code generate the unreadable code. I've seen systems that generate accessor functions, in particular. Might as well generate the fastest code.

I would certainly go this way. The Makefile for the package can certainly include a small script that would turn sub setx { my ($self, $value) = @_; $self->{_x}=$value; } into sub setx { $_[0]->{_x} = $_[1] }

This is actually what I do for XML::Twig: the code I maintain is in Twig.pm.slow, and the Makefile.PL includes the following line:

'depend' => { 'Twig.pm' => "Twig.pm.slow\n\t\$(PERL) speedup Twig.pm.slow > Twig.pm"}

Note the use of \$(PERL) which finds the proper perl even if the command is /usr/local/bin/weird-perl Makefile.PL instead of the perl that's in the path.

speedup does things like:

$SET_FIELD="first_child|next_sibling|pcdata|cdata|ent|data|target|comm +ent|flushed"; s{(\$[a-z_]+(?:\[\d\])?) # $1: the object ->set_($SET_FIELD) # $2: the field to set \(([^)]*)\)} # $3: the value (must not include + ()) {$1\->\{$2\}= $3}gx;

This replaces proper accessors by direct access to the hash.

Replies are listed 'Best First'.
Re: Re: Re: Micro optimisations can pay off, and needn't be a maintenance problem
by John M. Dlugosz (Monsignor) on Nov 13, 2002 at 17:10 UTC
    Hmm, I think I would prefer to keep it all in one file, perhaps putting the "original" in a =tobespeeded/=cut section.

    But, I like the idea. You are basically inlining the functions that the compiler can't.

    However, it also loses any polymorphism. That is, it becomes non-virtual.

      Yes, it looses polymorphism, or at least it prevents a subclass to replace those methods. The main advantage is that I can keep the code rather clean and OO, while getting the speed bonus of not having methods internally (about a 30% gain in my tests). And if in the future I want to change the implementation I can, I just have to remember to remove the field from the list. An alternative suggested by tilly was to just use the hash and to switch to a tied hash when needed (Re (tilly) 1: Speeding-up OO accessor methods).

      BTW I looked into doing real inlining (including with the pre-processor) but did not find a way at the time (4 years ago). It might be feasable now, with a source filter. Now that would be a useful module!