in reply to Re^4: keys and values order on a hash
in thread keys and values order on a hash

Nothing, it's a benchmark. It's the nature of benchmarks to consider code in isolation, with as minimal side-effects as possible to measure the differences.

Then your benchmark is broken. All you've done is bias the benchmark to favour your opinion, which is utterly pointless.

Once you start doing something with the keys and values, avoid creating large arrays is a part and parcel of what makes each more efficient.

And for your "too many caveats" argument: the semantics are clearly defined and obvious. If they are too complicated for you to bother with that's your call, but others may be less stressed by that 'complexity'.

Me for example. I mention the possibility here because *I* find it useful, and others might also.

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.

Replies are listed 'Best First'.
Re^6: keys and values order on a hash
by Somni (Friar) on Jul 11, 2011 at 19:30 UTC
    Then please, implement a benchmark that exhibits the savings you are concerned about. My benchmark was simply to show that it was not a given that 'each' is faster (or better). The reason they are building arrays is to validate each function does the same thing; given they are both doing the same thing in that regard, the only difference is in the raw speed of an 'each' (and push) loop vs. getting a list of values from keys and values.

    Indeed, the semantics of 'each' are clearly defined and obvious. The results of those semantics in a large body of code is not. It's essentially an action-at-a-distance effect. Understanding how that became a problem (in the event it does), and how to find what did it, can make for a very difficult bug to track down.

    This is essentially the same reason global variables are generally avoided. If you can always avoid the problems with 'each', and do so when others are looking at and maintaining your code, please, let us all know how you accomplish it; it would go a long way to redeeming 'each' in my opinion, at least.

[reply]
      Then please, implement a benchmark that exhibits the savings you are concerned about. 

      #! perl -slw
use strict;
use Benchmark qw[ cmpthese ];

our %hash = 'aaaaa' .. 'dzzzz';

cmpthese 1, {
    a => q[
        my @keys = keys %hash;
        my @vals = values %hash;
        my $x;
        $x = "$keys[ $_ ] :: $vals[ $_ ]" for 0 .. $#keys;
    ],
    b => q[
        my( $k, $v, $x );
        $x = "$k :: $v" while ( $k, $v ) = each %hash;
    ]
};

__END__
  s/iter    a    b
a   3.06   -- -41%
b   1.79  70%   --

      [download]
      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.
[reply]
[d/l]

In Section Seekers of Perl Wisdom