develooper Front page | perl.perl5.porters | Postings from March 2015


Thread Previous | Thread Next
Paul "LeoNerd" Evans
March 5, 2015 18:34
Message ID:
On Thu, 5 Mar 2015 18:22:44 +0000
"Paul \"LeoNerd\" Evans" <> 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  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About