Re^3: What are the other option for sorting the keys of hash of hashes

No, this is quite efficient. Hash accesses are very fast.

But if you really think you need every cycle, you might try the following

use warnings;
use strict;

my %hash= ('a' => {'Size' => 40 },
       'b' => {'Size' => 3000 },
       'c' => {'Size' => 20 },
       'd' => {'Size' => 1 },
       'e' => {'Size' => 12 } 
);


my @unsort= map ( $hash{$_}->{"Size"} .':' . $_ , keys %hash);

no warnings;
my @sort= sort {$a<=>$b } @unsort;
use warnings;

foreach (@sort)  { 
  s/[^:]*://;
}

print join'  ',@sort,"\n";

# prints

d  e  c  a  b
[download]

You really should test whether you get any speedup through this, you need fairly large hashes to see any difference at all, as you trade two hash accesses for two string-to-int conversions per sort operation. I'm not sure what will win

Instead of turning off the warnings you could also normalize the size numbers for the sorting by putting '0' before each number so that all numbers are the same size and extract the numbers in the sort routine, but that will definitely eat up any speedup over your original sort

UDPATE: Yes, forgot the Schwarzian Transform, again.

Comment on Re^3: What are the other option for sorting the keys of hash of hashes Download Code

Replies are listed 'Best First'.
Re^4: What are the other option for sorting the keys of hash of hashes by johngg (Canon) on Sep 29, 2008 at 15:19 UTC
No, this is quite efficient. Hash accesses are very fast ... You really should test whether you get any speedup through this Here is some benchmark code that explores this. Read more... (1425 Bytes) The output. `Rate Simple ClassicST Jethro ClassicGRT Simple 11.3/s -- -13% -46% -55% ClassicST 13.0/s 16% -- -37% -48% Jethro 20.8/s 84% 59% -- -17% ClassicGRT 25.0/s 122% 92% 20% --` [download] Your sorting code is a bit odd in that it appears to be a halfway house between a ST and a GRT. It has some issues with "numeric" warnings and a reliance on Perl doing the right thing (which is does at the moment but perhaps that might change) when doing a numerical sort on non-numerical strings that happen to have leading digits. It is pretty quick though, only beaten by the GRT. I have altered your code a bit by using simple interpolation in the `map` instead of concatenation and by localising and better targetting the `no warnings` instruction. The usual caveats apply regarding my benchmarks. I've cocked them up before and I'm sure I will again. Cheers, JohnGG Update: Corrected typo, `s/you/your/`	[reply] [d/l] [select]
Re^5: What are the other option for sorting the keys of hash of hashes by salva (Canon) on Sep 29, 2008 at 16:30 UTC
The GRT code you are using packs the numbers as 32 bits which is not a good thing to do for file sizes nowadays! Anyway, I have added code to benchmark the sorting algorithms provided by Sort::Key and Sort::Key::Radix... Read more... (824 Bytes) and these are the results: `Rate Simple ClassicST ClassicGRT Jethro SK + SKR Simple 3.08/s -- -45% -69% -70% -78% + -80% ClassicST 5.64/s 83% -- -42% -45% -60% + -63% ClassicGRT 9.79/s 218% 74% -- -5% -31% + -36% Jethro 10.3/s 234% 83% 5% -- -27% + -32% SK 14.1/s 359% 151% 44% 37% -- + -7% SKR 15.2/s 394% 170% 55% 48% 8% + --` [download]	[reply] [d/l] [select]
Re^5: What are the other option for sorting the keys of hash of hashes by jethro (Monsignor) on Sep 29, 2008 at 16:21 UTC
The same reliance on doing the right thing caveat has to be applied to ClassicGRT as well. If at some point perls string comparision puts Umlauts at their right place, that sort will fail. Also I'm not sure what happens in perl even now when the string is an utf8 string and the number would be a multi-byte character in utf8	[reply]