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

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

Thread Previous | Thread Next
Dave Mitchell
November 3, 2014 12:36
Re: [perl #3306] DESTROY not called on code reference objects
Message ID:
On Wed, Oct 29, 2014 at 09:38:43PM -0700, Father Chrysostomos via RT wrote:
> 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. :-)

"There is nothing new under the sun" :-)

> 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).
> 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?

Well, 'sub {} for 1..10_000_000' is a bit of a contrived benchmark; in the
real world, one might typically expect a newly created anon sub to be
stored somewhere, and to be called at least once; and for that sub to do a
minimal amount of work. In that case, the extra work done might make the
savings in clone time mere noise. Consider this benchmark:

    my $r = { foo => 1 };
    for (1..10_000_000) {
        #sub {};
        my $x = sub {$_[0]{foo} };
        my $y = $x->($r);

which represents a fairly minimal non-closure anon sub that does
something accessor-ish. Running with just the sub {} line takes 0.614s.
Running instead with the $x and $y lines takes 3.339s. Assuming the times 3
slowdown you got with your hacked perl and I got with my hacked perl, that
would add 0.678s for the sub cloning, which would change the 'real world'

    from:  3.339s
    to:    4.017s

a slowdown of 20%.

I think this would be at the margins of acceptability.

> 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.

I think the fact that blessing one sub blesses them all is a fairly
serious bug too.

If life gives you lemons, you'll probably develop a citric acid allergy.

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