From The RT System itself

This will recompile the code through every iteration, which is
not realistic. Try repeating using the sub {} style.

Conclusions & Questions

1) Function calls (P​::F(...)) sped up 15% from _03 -> _57, then settled
back to 4% when looking at _03 -> _58.

2) my $self = shift @​_ ; slowed down enough in _58 to overcome the gains
in function call speed (compare P​::m(...) results to P​::f(...)). Method
calls are no faster overall (including $self shift overhead) in _61 than
in _03

3) Wonder why P->f(...) slowed down 4%, while $o->f(...) sped up 4% in
_57 -> _58. The trend continued in _58 -> _61. $o->f(...) shines when
looking at _57 -> _61.

4) Wonder why P->m(...) and $o->m(...) didn't speed up more in _57 when
P->f(...) did. Probably too tired right now to see it.

5) Wonder why P->f(...) slowed down in _58, while $o->f(...) sped up.

I have no real explanation for your numbers, but I think I can
understand one aspect of the results.

5.005_58 introduced Chip's OP_METHOD_NAMED patch, which adds a
ck_method() check during compilation of every method call. If
we just naively go by the number of instructions in the code
path, this should slightly increase the compilation time, but
correspondingly result in reduced run time of P->foo(). So
some of the work that used to be done at run time is done at
compile time, but your benchmark compiles it once every time
through, while also calling the method only once. This would
result in no net advantage.

Sarathy
gsar@​activestate.com

@iabyn - Status changed from 'stalled' to 'resolved'