On Wed Aug 22 08:03:08 2012, dagolden@cpan.org wrote: > This ticket suggests a possible peephole optimization, should someone > be interested in pursing it. It is based on a discussion I had with > Nicholas Clark and I agreed to write it up so the idea wouldn't be > lost. > > In short, a huge number of pure Perl subroutines start off like this: > > sub foo { > my ($one, $two) = @_; > ... > } > > This assignment requires multiple OPs to execute: > > $ perl -MO=Concise,foo,-exec -e 'sub foo {my ($one, $two) = @_; dump > }' > main::foo: > 1 <;> nextstate(main 1 -e:1) v > 2 <0> pushmark s > 3 <#> gv[*_] s > 4 <1> rv2av[t4] lK/1 > 5 <0> pushmark sRM*/128 > 6 <0> padsv[$one:1,2] lRM*/LVINTRO > 7 <0> padsv[$two:1,2] lRM*/LVINTRO > 8 <2> aassign[t5] vKS > 9 <;> nextstate(main 2 -e:1) v:{ > a <0> dump s* > b <1> leavesub[1 ref] K/REFC,1 > > If this is predictable and detectable at the start of a subroutine -- > albeit with a variable number of padsv's being assigned -- then it > should be possible for the peephole optimizier to replace them with a > new, single OP that copies an arbitrary number of SV's directly from > the > stack to the pad. Depending on the overhead of such a peephole check > on > every sub, this could potentially speed up code with many small > subroutines such as occurs in highly-factored code. > > (I don't know if similar optimization could be made to work -- or > would > be worthwhile -- for shift or array/hash assignment.) One thing you would have to be careful of is &foo-style calls, that share @_. XS modules can get the caller’s arguments via get_av("_"), and any sub call could potentially be an XS call. I don’t think this optimisation is possible. -- Father Chrysostomos --- via perlbug: queue: perl5 status: new https://rt.perl.org:443/rt3/Ticket/Display.html?id=114536Thread Next