Russ has asked for the wisdom of the Perl Monks concerning the following question:
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...)
Output:#!/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; } });
So, now it's once again my turn to learn (happens all the time around here -- I love Perl Monks)...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)
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)).
|
---|
Replies are listed 'Best First'. | |
---|---|
RE: Schwartzian Transform vs. plain Perl
by mikfire (Deacon) on Jun 08, 2000 at 16:38 UTC | |
RE: Schwartzian Transform vs. plain Perl
by jjhorner (Hermit) on Jun 08, 2000 at 16:44 UTC | |
by mikfire (Deacon) on Jun 08, 2000 at 17:50 UTC | |
(jcwren) Re: Schwartzian Transform vs. plain Perl
by jcwren (Prior) on Jun 08, 2000 at 17:14 UTC |