Front page | perl.perl5.porters |
Postings from November 2014
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