An idea for 5.37:
Everywhere that OP_ANONCODE appears in the optree of normal code, it's
surrounded by an OP_REFGEN op, to make a reference SV out of the bare
CV that OP_ANONCODE created.
It would be quite easy to define the OPf_REF flag on the OP_ANONCODE op
to do this step internally, meaning it didn't need a separate op. That
would result in a small memory saving of the optree, and a runtime
performance boost; perhaps enough to be measurably useful in code that
uses lots of higher-order functions and closures, and generally does
this sort of thing a lot.
The change would be fairly small, quite easy to write tests for, and an
excellent candidate for someone new to core development who wanted to
dip their toes in the water.
If anyone wants to take a look at that in the 5.37 round, give us a
wave and I can walk you through it...
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Everywhere that OP_ANONCODE appears in the optree of normal code, it's
surrounded by an OP_REFGEN op, to make a reference SV out of the bare
CV that OP_ANONCODE created.
It would be quite easy to define the OPf_REF flag on the OP_ANONCODE op
to do this step internally, meaning it didn't need a separate op. That
would result in a small memory saving of the optree, and a runtime
performance boost; perhaps enough to be measurably useful in code that
uses lots of higher-order functions and closures, and generally does
this sort of thing a lot.
The change would be fairly small, quite easy to write tests for, and an
excellent candidate for someone new to core development who wanted to
dip their toes in the water.
If anyone wants to take a look at that in the 5.37 round, give us a
wave and I can walk you through it...
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/