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


Thread Previous | Thread Next
Paul "LeoNerd" Evans
March 5, 2015 18:22
Message ID:
On Thu, 5 Mar 2015 18:20:58 +0100
Aristotle Pagaltzis <> wrote:

> IIUC (both you and Paul) then you missed Paul’s point. AIUI, he meant
> OP_ZERO as a special-purpose form of OP_SASSIGN, not a special-cased
> form of OP_CONST.

Indeed, I did mean that.

I mean that if we create an OP_ZERO, an OP_EMPTY, an OP_CONSTASSIGNIV,
OP_CONSTASSIGNPV, then we can peephole each of the following into a
single op each:

  $lexvar = 0          ===>  OP_ZERO(TARG=$lexvar)
  $lexvar = ""         ===>  OP_EMPTY(TARG=$lexvar)
  $lexvar = 123        ===>  OP_CONSTASSIGNIV(TARG=$lexvar, IV=123)
  $lexvar = "hello"    ===>  OP_CONSTASSIGNPV(TARG=$lexvar, PV="hello",

*REGARDLESS* of where they appear; whether in signature code or
otherwise. Right now that's an OP_SASSIGN + OP_CONST in each case,
needlessly bouncing the assigned value as a temp SV on the stack. Those
four new ops I mention above would remove that, and speed up code
wherever it was found.

Maybe, in a real program (i.e. one whose runtime is not significantly
composed of signature-decomposition in trivial sub bodies) would
benefit from that speed-boost *more* than it would benefit
OP_SIGNATURE, and these ops could then be used as some of the building
blocks in a more orthogonally-designed and generic signature
implementation mechanism.

I can only say maybe as I haven't tried implementing or benchmarking
it yet.

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?

Paul "LeoNerd" Evans  |

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