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:

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;
[download]

This replaces proper accessors by direct access to the hash.

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!

Indeed, positioning the use constant... calls inside the function body in the short example is misleading. Sorry.

As constants constructed this way become constant subs, they end up having package scope just as any sub would. It probably makes sense to have them grouped at the top of the package as shown in the benchmark code, or grouped above the sub which they are related to if the package is bigger, but in anycase, in a position where their scope is (more) obvious from their position. I'll change that. Thanks.