Re^4: To use a module...or not.

Actually, it runs a fair bit quicker than either of my GRT versions. However, it does share the flaw that my first attempt at a GRT had; namely that there is no way to associate the keys with the resultant sorted values--which was a requirement for the OP.

I'm not sure that there is any easy fix for that using an indexed sort on this type of data, but for shear speed it is hands down winner.

P:\test>376443 -NMAX=10 -AMAX=J >null
100 trials of ST (32.970s total), 329.704ms/trial

100 trials of GRT1 (15.892s total), 158.917ms/trial

100 trials of GRT2 (21.531s total), 215.313ms/trial

100 trials of indexed (8.344s total), 83.438ms/trial

100 trials of indexed2 (10.531s total), 105.313ms/trial
[download]

'indexed' is your code as posted. 'indexed2' is the same but using maps.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

Comment on Re^4: To use a module...or not. Download Code

Replies are listed 'Best First'.

Re^5: To use a module...or not.
by Aristotle (Chancellor) on Jul 28, 2004 at 11:39 UTC

there is no way to associate the keys with the resultant sorted values--which was a requirement for the OP.

I didn't see that. To be honest I thought his requirements were somewhat poorly specified. In any case, you can just swap value-ordering for key-ordering by saying

( keys %hash )[ order_of_sorted keys %hash ]
[download]

You then have to fetch the values in an extra step by looking up the keys. That's additional work, but you have the keys available in $outer and $inner for later perusal.

This just goes to show my point: separating the problems well improves maintainability.

Makeshifts last the longest.

[reply]
[d/l]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks