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 | |
by mirod (Canon) on Nov 13, 2002 at 17:50 UTC |