Hopefully, this is an interesting question about the Schwartzian Transform and Perl internal performance:

I thought I was going to demonstrate the performance advantage of the Schwartzian Transform by applying it to the three-way sort code posted by BBQ. It is slower, however, with my quick implementation (which looks right...)

#!/usr/bin/perl -w
use Benchmark;
timethese(100, {
  a => q{
    my %hash = (key1 => 3, key2 => 2, key3 => "test");
                # I used 10000 more for a large test set (omitted for 
+brevity)
    @keys = sort {
      $hash{$b} cmp $hash{$a}
        ||
      length($b) cmp length($a)
        ||
      $b <=> $a
    } keys %hash
  },
  b => q{
    my %hash = (key1 => 3, key2 => 2, key3 => "test");
                # I used the same 10000 more as above
    @keys =
      map  { $_->[0] }
      sort {
        $b->[1] cmp $a->[1]
          ||
        $b->[2] <=> $a->[2]
          ||
        $b->[0] cmp $a->[0]
      }
      map{ [$_, $hash{$_}, length $_] }
      keys %hash;
  }
});
[download]

Output:

Benchmark: timing 100 iterations of a, b...
         a: 274 wallclock secs (272.26 usr +  0.22 sys = 272.48 CPU)
         b: 366 wallclock secs (359.06 usr +  0.52 sys = 359.58 CPU)
[download]

So, now it's once again my turn to learn (happens all the time around here -- I love Perl Monks)...

The Schwartzian Transform is all about reducing the computational difficulty of comparison code during complicated sorts. In this case, I assumed that two hash lookups, followed by two string length calculations, finally followed by a plain comparison would easily qualify as a "complicated" sort block.

What's happening, here? Why does it take longer to dereference and index into an array than to do hash lookups and length() calls?

Russ

P.S. My omitted data had all of the values equal (to force the comparison to always do the most work). It is just generated with map(($_, 1), (1..10000)).