Re^2: keys and values order on a hash

each has its own problems in terms of maintainability. Bailing out of the loop early (perhaps an exception was hit, perhaps there was a return or last) will leave the iterator in the middle of the hash.

> perl -wE '
    sub p {
        my($h) = @_;
        while (my($k, $v) = each %$h) { return "$k=$v" }
    }

    my %h = qw( one 1 two 2 three 3 );
    say p(\%h);
    say p(\%h);
    say p(\%h);
'
three=3
one=1
two=2
[download]

This can lead to some subtle hard to trace bugs. I've been personally bitten by this several times, and I've essentially dropped each from my toolkit; it's simply too easy to leave the iterator in a strange spot.

I also wouldn't be too sure of your optimization suggestion. With a pretty basic benchmark I slapped together (source here) it would appear separate keys/values is faster:


> ./each-vs-key-values.pl 
BEGIN, hash: short
Benchmark: running each, keys_values for at least 5 CPU seconds...
      each:  6 wallclock secs ( 5.26 usr +  0.01 sys =  5.27 CPU) @ 44
+213.85/s (n=233007)
keys_values:  6 wallclock secs ( 5.63 usr +  0.01 sys =  5.64 CPU) @ 1
+07908.33/s (n=608603)

                Rate        each keys_values
each         44214/s          --        -59%
keys_values 107908/s        144%          --
END, hash: short

BEGIN, hash: long
Benchmark: running each, keys_values for at least 5 CPU seconds...
      each:  7 wallclock secs ( 5.83 usr +  0.00 sys =  5.83 CPU) @ 16
+6.38/s (n=970)
keys_values:  6 wallclock secs ( 5.30 usr +  0.00 sys =  5.30 CPU) @ 6
+95.09/s (n=3684)

             Rate        each keys_values
each        166/s          --        -76%
keys_values 695/s        318%          --
END, hash: long

BEGIN, hash: alphabet
Benchmark: running each, keys_values for at least 5 CPU seconds...
      each:  5 wallclock secs ( 5.24 usr +  0.01 sys =  5.25 CPU) @ 36
+26.29/s (n=19038)
keys_values:  5 wallclock secs ( 5.20 usr +  0.00 sys =  5.20 CPU) @ 1
+3917.12/s (n=72369)

               Rate        each keys_values
each         3626/s          --        -74%
keys_values 13917/s        284%          --
END, hash: alphabet
[download]

This is with a Debian Lenny perl 5.10.1. I'm speculating the overhead of the multiple each calls is killing any gains you get from not iterating a second time; that, or the iteration is cheap because of how the HV is built.

Comment on Re^2: keys and values order on a hash Select or Download Code

Replies are listed 'Best First'.
Re^3: keys and values order on a hash by BrowserUk (Patriarch) on Jul 11, 2011 at 18:44 UTC
Once you've got all those keys and values into those two separated arrays, what are you going to do with them? 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]
Re^4: keys and values order on a hash by Somni (Friar) on Jul 11, 2011 at 19:05 UTC
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. It doesn't measure a whole program, or what affect each solution may have. However, this is also the nature of premature and micro-optimizations. The point of the benchmark was simply to show that assuming keys/values is slower than each is not always correct. Any decisions beyond that should only be measured based on actual code, with a profile, and an indication that this part of the code is the bottleneck.	[reply]
Re^5: keys and values order on a hash by BrowserUk (Patriarch) on Jul 11, 2011 at 19:15 UTC
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.	[reply]
Re^6: keys and values order on a hash by Somni (Friar) on Jul 11, 2011 at 19:30 UTC
Re^7: keys and values order on a hash by BrowserUk (Patriarch) on Jul 11, 2011 at 20:11 UTC


Perl Monk, Perl Meditation
	PerlMonks