Re: Re: May Thy Closures Be Blessed

[eserte]

This is probably due to inefficient stringification of the object reference. Maybe the stringified value should be put into the PV portion and POK should be set on while doing Perl_sv_2pv_flags ?

[adrianh]

This is probably due to inefficient stringification of the object reference. Maybe the stringified value should be put into the PV portion and POK should be set on while doing Perl_sv_2pv_flags ?

I think this evaluation is spot on. If you change the inside-out implementation to something that avoids stringification:

Read more... (1057 Bytes)

You get something much more reasonable:

             Rate     closure  inside_out traditional
closure     177/s          --        -43%        -45%
inside_out  313/s         76%          --         -3%
traditional 321/s         81%          3%          --

[Abigail-II]

Very nice. Big savings because of caching the calculation of stringified value (I get an 18% difference, not a 3%). Unfortunally, this technique can't be used if you are subclassing a class that doesn't coorperate - then you will to call refaddr in each method. That's slower (traditional method being 69% faster), but faster than what I showed before. I would have expected to be able to gain a little more by writing the methods like:

sub name {
    my $key = ${+shift};
    $name {$key} = shift if @_;
    $name {$key};
}

but that doesn't give me any gain (or loss).

Abigail

[adrianh]

I get an 18% difference, not a 3%

Hmm. I do seem to have been lucky with my initial runs. I'm seeing between 3-10% on my box, but nothing near 18%. How odd.

Unfortunally, this technique can't be used if you are subclassing a class that doesn't coorperate

True. Although for hash based objects you could just use one slot for the key and still get safety for all your other state hashes.

I would have expected to be able to gain a little more by writing the methods like ...

Good point. Can any internals expert explain why +shift is so slow?