Front page | perl.perl5.porters |
Postings from October 2014
Ah! I found it!
This is the ticket I was looking for. I discussed this same issue in <20141028053445.4478.qmail@lists-nntp.develooper.com>. The ideas that I thought were my own have already been suggested and discussed here. :-)
On Sat May 06 15:55:35 2006, davem@iabyn.com wrote:
> On Mon, May 01, 2006 at 07:55:21PM +0100, Dave Mitchell wrote:
> > I should imagine it's copying the scratchpad that takes most of the time.
> > Hmm, perhaps we could just share the scratchpads for non-closure anon
> > subs?
>
> I've knocked up a proof-of-concept patch (it fails loads of tests, but
> works for basic code).
>
> The timings I get are as follows:
>
> orig perl (share CV and scratchpad):
>
> 0m2.292s sub {} for 1..10_000_000
>
> hacked perl (copy CV, but share scratchpad):
>
> 0m6.564s sub {} for 1..10_000_000
>
> orig perl, but full closure (CV and scratchpad copied):
>
> 0m18.229s my $x; sub {$x} for 1..10_000_000
With my hacked-up perl on the sprout/padlist-sharing branch (which fails about 20 test scripts), I get:
orig perl (share CV and scratchpad):
0m0.980s sub {} for 1..10_000_000
hacked perl (copy CV, but share scratchpad):
0m3.130s sub {} for 1..10_000_000
orig perl, but full (dis)closure (CV and scratchpad copied):
0m9.695s my $x; sub {$x} for 1..10_000_000
So sub{} that returns a new sub each time is only a third of the speed.
Is that acceptable?
I think the most compelling reason for fixing this is that the behaviour is different under the debugger. If one’s code is not working, but it just magically does the right thing in the debugger, that’s scary action at a distance, making these sorts of problems hard to track down.
>
> However, there's a problem with copying the CV while sharing the pad:
> If one of the sub calls another copy of the sub, then they share the
> same set of lexicals and temps. The following contrived example shows
> how the inner call corrupts the outer sub's $x:
>
> push @s, sub { my $x=1; $s[0] && &{pop @s}; print "x=$x\n" } for 1,2;
> &{pop @s};
>
> which gives:
>
> x=1
> x=
>
> whereas in normal perl it gives
>
> x=1
> x=1
>
> this is becuase with the CV being shared, they share CvDEPTH and thus
> when one sub calls the other, CvDEPTH gets incremented and so they use
> different levels in the pad.
That problem I don’t have because I followed your suggestion of putting CvDEPTH in the padlist.
--
Father Chrysostomos
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=3306
Thread Previous
|
Thread Next