Felix Geerinckx wrote at Wed, 29 May 2002 17:17:38 +0200:
> on Wed, 29 May 2002 16:10:40 GMT, [EMAIL PROTECTED] (Janek Schleicher) wrote:
>
>> Oops, there's a typo :-((
>>
>> Of course, I meant
>> @sorted = reverse sort { $myhash{$a} <=> $myhash{b} } keys %myhash;
>
> There's another typo.
Year, I must have been drunken :-(
> And I'd rather add
>
> # sort keys in descending numerical order
>
> than suffering a substantial speed penalty by using 'reverse'.
Allthough, I can't get familiar with the exchanging of $a and $b.
When I try to read a source code, I see
sort { ${} <=> ${} } ...
and I expect that the sort routine goes normal.
I checked now for the first time,
how much time an extra reverse cost.
I had always expected that the compiler does a code optimization
for itself,
when he sees reverse sort { ... },
there shouldn't be a problem to interprete it. as
sort { -(...) }.
However perl does not.
But the last syntax is as quick as the normal sort routine:
use Benchmark;
my @list = ();
push @list, rand() while ($i++ < 500_000);
timethis( 100, sub {sort {$a <=> $b} @list} );
timethis( 100, sub {sort {-($a <=> $b)} @list} );
prints:
timethis 100: 2 wallclock secs ( 2.84 usr + 0.01 sys = 2.85 CPU) @ 35.09/s (n=100)
timethis 100: 3 wallclock secs ( 2.85 usr + 0.00 sys = 2.85 CPU) @ 35.09/s (n=100)
So I decided for myself,
to write reverse sort { ... } when
it's not time critical and the lists are small
and to write sort { -(...) } when it's time critical.
(I like it more than writing a command - the program has to be self explaining)
Thanks a lot to Felix for his hint.
Greetings,
Janek
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
