Re^7: Perl is dying (better sorting than the ST)

[demerphq]

Er, maybe im missing something here, how is an ST any different from what you have done in terms of big O. Leaving the sort aside since presumably it is as efficient either way, it appears to me that with an ST you have N steps to create the arrays, and N steps to unpack them, with your code you have N steps to create the key array, and N steps to map the sorted keys back to real values.

It strikes me that your routine might be more efficient because the unit cost of each step will be cheaper, but that seems to me to be a form of optimisation that could be argued should be left to the compiler.

So what am I missing?

Also, if you are going down this route you might as well go as far you can. According to benchmark the true GRT I whipped up for this is about 50% faster than your routine, and uses less memory (by two whole AV's :-).

use strict;
use warnings;
use Benchmark qw(cmpthese);

my @a_of_a = map { [($_) x 5] } 
            qw( a list of words to sort but the list needs to be fairl
+y
            long so we will blab on a bit just because we have to
            which sorta sucks because it would be more interesting
            to write code or eat ice-cream );
my @grt;
my @ari;

cmpthese -2,{
    grt => sub {
        my 
        @grt = map { $a_of_a[unpack"x4N",$_] } 
                 sort map { pack "A4N", lc $a_of_a[$_][ 4 ], $_ } 
                 0..$#a_of_a;
    },

    ari => sub  {             
        my 
        @ari = do {
            my @key = map { lc substr $_->[ 4 ], 0, 3 } @a_of_a;
            my @idx = sort { $key[ $a ] cmp $key[ $b ] } 0 .. $#key;
            @a_of_a[ @idx ];
        };
        
    }    
};
if (@grt) {     
    for (0..$#a_of_a) {
        if ( $ari[$_] != $grt[$_] ) {
            die "$_ is bad\n";
        }
    }
}
    
__END__    
      Rate  ari  grt
ari 3946/s   -- -37%
grt 6260/s  59%   --
      Rate  ari  grt
ari 4111/s   -- -33%
grt 6179/s  50%   --
      Rate  ari  grt
ari 3989/s   -- -38%
grt 6393/s  60%   --
      Rate  ari  grt
ari 4049/s   -- -36%
grt 6300/s  56%   --
      Rate  ari  grt
ari 3982/s   -- -38%
grt 6467/s  62%   --

Because the GRT avoids the substr, needs no indirection on the key which in turn means you dont need provide a custom sort function which in turn means the per cost of each comparison is quite a bit lower. AND you get the added bonus that the sort is stable, and a lower memory profile.

But it also arguable that this too is a form of premature optimisation.

Update: when i compare your approach to a ST like the following, i see no performance difference between it and your approach.

    st => sub  {             
        my 
        @st =  map { pop @$_; $_ }
               sort { $a->[-1] cmp $b->[-1] } 
               map { my $k = lc substr $_->[ 4 ], 0, 3; push @$_,$k;  
+$_ }
               @a_of_a;
    }