http://www.perlmonks.org?node_id=888489


in reply to Re^3: Unpacking and converting
in thread Unpacking and converting

I think in this case the array creation and population makes significant influence on results. Consider this

You missed the point. The shifting of elements from the array makes it empty after first iteration. But Benchmark makes thousands of iteration within 1 second. All of those iterations work with empty array, this explains why this approach appears to be "faster".

Replies are listed 'Best First'.
Re^5: Unpacking and converting
by BrowserUk (Patriarch) on Feb 16, 2011 at 15:51 UTC

    Thank you for giving me my D'oh moment for today.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re^5: Unpacking and converting
by dwalin (Monk) on Feb 16, 2011 at 14:01 UTC
    The shifting of elements from the array makes it empty after first iteration.

    Ugh, I seem to be extra stupid today. But hey, it's not that easy still:

    my @s = '0001' .. '1000'; cmpthese -1,{ d => q[ my @d = @s; ], c => q[ my @c = @s; $c[ $_ ] += 0 for 0 .. $#c; ], a => q[ my @a = @s; $_ += 0 for @a; ], b => q[ my @b = @s; my @new; push @new, $_ + 0 while defined( $_ = + shift @b ) ], };
    Yields:
    Rate c a b d c 793688/s -- -59% -59% -84% a 1941807/s 145% -- -0% -60% b 1942492/s 145% 0% -- -60% d 4812084/s 506% 148% 148% --
    So what do we have, shifting and for (@list) are equally fast? Not so:
    my @s = '0000001' .. '1000000'; cmpthese -1,{ d => q[ my @d = @s; ], c => q[ my @c = @s; $c[ $_ ] += 0 for 0 .. $#c; ], a => q[ my @a = @s; $_ += 0 for @a; ], b => q[ my @b = @s; my @new; push @new, $_ + 0 while defined( $_ = + shift @b ) ], };
    Gives these results:
    Rate c b a d c 764586/s -- -58% -62% -85% b 1803742/s 136% -- -10% -65% a 2007409/s 163% 11% -- -61% d 5119310/s 570% 184% 155% --
    Which is logical, at last. Scandal of the century is averted, I stand corrected - the only thing I have to find out is why my tests on actual data consistently show shifting to be faster than for (@list). Not several orders of magnitude faster as it was in that faulty benchmark but considerably so. I believe I have to look for an error...

    Regards,
    Alex.