develooper Front page | perl.perl5.porters | Postings from March 2011

Re: [perl #82110] Still "keys" performance regression between 5.10.1and 5.12.3-RC1

Thread Previous | Thread Next
Dave Mitchell
March 12, 2011 12:58
Re: [perl #82110] Still "keys" performance regression between 5.10.1and 5.12.3-RC1
Message ID:
On Sat, Mar 12, 2011 at 01:51:46PM +0100, demerphq wrote:
> Am I right in understanding that our position is that a 30% slowdown
> in "my @array= list " is an acceptable cost

Note its only these two

    my @array = @$arrayref;
    my %hash  = %$hashref;

that get the pessimisation, and not the more general versions of

    my @array = something;
    my %hash  = something;

> I personally do not think that this is so clear cut, given that they
> can do this:
>      my $r;
> again:
>      my @x;
>      @x = @$r; # *** common assignment on 2nd attempt!
>      print "@x\n";
>      @x = (1,2,3);
>      $r = \@x;
>      goto again unless $i++;
> And have it work correctly?

I'm not sure what point you're trying to make here. In that code, the
@x = @$r is pessimised, and always has been. The only change made in 5.1.20
onwards is that formerly, it was assumed that code starting with a my
declaration, i.e.
    my @x = ...
could always be optimised, because it was impossible at that point for @x
to have any elements. FC's closure example, and then my goto example, both
demonstrate that it is possible at the point of executing the PADAV/INTRO,
for @x to already have gained elements. Thus we now recognise that there
are some cases where this assumption isn't true.
> I have not fully understood FC's closure case properly, so maybe this is
> an easier trap to fall into than I think, but right now I'm thinking
> this is a pessimisation that is much akin to make $1 "safe" after a //g
> in scalar context, a case where we decided that simply saying "don't do
> that" was better than making every //g match slower.
> IOW, I'm not sure that sacrificing performance on a very common
> construct to make what seems to me to be a pretty unusual edge case work
> properly is a good trade off especially given there is an easy work
> around.

I don't understand what you mean by a workaround.

> While I don't think id go so far as to say we should actually choosing
> speed over correctness is right here, I have to admit I'm tempted, and
> do think at the very least we should keep this bug open.

We're not talking speed over correctness here. We're talking speed over
panics and crashing.

Diplomacy is telling someone to go to hell in such a way that they'll
look forward to the trip

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