In case of many items the hash lookups can be reduced with a Schwartzian Transform, but it will eat more memory in turn, and likely to only give you a small speedup, if any.

moritz, i dont have any performance problem....
This is just for knowledge....
thanks

then, read the paper A Fresh Look at Efficient Perl Sorting by Uri Guttman and Larry Rosler, for an explanation of advanced sorting techniques in Perl.

Also, take a look at the Perl modules Sort::Maker (implements most of the methods described in the paper) and Sort::Key (probably the fastest).

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

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/

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]

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