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

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

Thread Previous | Thread Next
From:
John Siracusa
Date:
November 3, 2014 15:53
Subject:
Re: [perl #3306] DESTROY not called on code reference objects
Message ID:
CAJu6bqtdBRWut96hN6+TjPYE84+O8y8n4Y1MoYcBV4mKH+XwHg@mail.gmail.com
On Mon, Nov 3, 2014 at 7:36 AM, Dave Mitchell <davem@iabyn.com> wrote:

> 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
> > <20141028053445.4478.qmail@lists-nntp.develooper.com>.  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, 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).
> > 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'
> code
>
>     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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About