> On Sat, Oct 18, 2014 at 11:28:24PM -0000, Father Chrysostomos wrote: > > I also wonder why padrange insists that op_next be equal to > > op_sibling. The B overlay feature seems to complicate things, IMO. > > Well, if you want to fix up all the places in Deparse.pm that expect a > lexical var and fix them up, and add tests, be my guest! Maybe I should *look* before I speak! The overlay feature is helpful here. We just don't need to set op_next, since B::Deparse does not actually use it. And concerning the rest of the thread, my benchmarks show that in aslice and map padrange seems slightly slower than eliminating list & pushmark. So the latter optimisation should stay in list con- text. It was only in the contrived (0,($lex1,$lex2)) that padrange proved faster.Thread Previous | Thread Next