Front page | perl.perl5.porters |
Postings from March 2015
From: Paul "LeoNerd" Evans
March 5, 2015 18:34
Message ID: email@example.com
On Thu, 5 Mar 2015 18:22:44 +0000
"Paul \"LeoNerd\" Evans" <firstname.lastname@example.org> wrote:
> Oh, but also these would *immediately* speed up all of the existing
> CPAN modules, even those that don't use the 5.20+ signatures.
> Is that worth looking at?
To make more clear my overall objection to OP_SIGNATURE:
It seems to me you have very-specialcased one particular bit of
Perl's execution (that of interpreting signatures), and part that's
still officially experimental and only used by a
statistically-insignificant fraction of CPAN. A lot of the
optimisations you're applying (like nice shortcuts for assigning
zero, one, other constant integers, etc...) could apply in many other
parts of perl execution, yet you don't look at that.
I suspect if instead those optimisations were pulled out and
peepholed in elsewhere, we could make overall speed-up of *ALL* perl
code; whether or not it uses 5.20-style signatures. I'd be willing to
bet that in any realworld program, such generally-applicable
optimisations would make the overall program run faster still, than
if those optimisations were hidden and locked away in OP_SIGNATURE,
where they cannot be of any use to the vast majority of existing code
already on CPAN.
You might make signature-handling 20% slower than it would be via
OP_SIGNATURE, but if you make all the other code a little faster to
compensate (including don't forget within for loops, while loops,
other places that get hit much more often than function entry/exit)
maybe that would more than compensate for it?
Paul "LeoNerd" Evans
http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS