Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re: Speed of f(), $o->m(), etc. in 03,57,58,61 [Was: File::Spec::Functions in 5.005_61] #597

p5pRT opened this issue Sep 20, 1999 · 2 comments


Copy link

p5pRT commented Sep 20, 1999

Migrated from (status was 'resolved')

Searchable as RT1456$

Copy link

p5pRT commented Sep 20, 1999

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.


Copy link

p5pRT commented Apr 22, 2003

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant