develooper Front page | perl.perl5.porters | Postings from October 2014

[perl #3306] DESTROY not called on code reference objects

Thread Previous | Thread Next
Father Chrysostomos via RT
October 30, 2014 04:38
[perl #3306] DESTROY not called on code reference objects
Message ID:
Ah!  I found it!

This is the ticket I was looking for.  I discussed this same issue in <>.  The ideas that I thought were my own have already been suggested and discussed here. :-)

On Sat May 06 15:55:35 2006, 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

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