Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re^9: RFC:A brief tutorial on Perl's native sorting facilities.

by jdporter (Canon)
on Feb 07, 2007 at 01:19 UTC ( #598664=note: print w/replies, xml ) Need Help??

in reply to Re^8: RFC:A brief tutorial on Perl's native sorting facilities.
in thread RFC:A brief tutorial on Perl's native sorting facilities.

With only three items in the list, you're never going to see the performance advantage of the default sort; all the other effects dominate. Try it with 1_000 or 10_000 items.

Update: Wups - I totally missed the fact that the number of items in the list is controlled by a run-time parameter. Sorry.

So I did my own benchmark, and I found that what BrowserUk calls 'GRTish' was faster. Why? One difference between his benchmark and mine was the key calculation routine, convertdate. I didn't have Date::Calc installed, and didn't want to install it just for this test, so I made mine be simply

sprintf "%20s", $_[0]
Could that be the source of the difference in results?

To check this possibility, I made my key calculation more expensive:

sprintf '%20s', 2.2 / ( 2.2 / ( int( $_[0] * 8.00001 ) >> 3 ) )
(That's a couple of chained math no-ops).

Sure enough, KEY performed better than GRTish. And Decode_Date_US is, no doubt, a very costly function.

Still — Why should the performance of this key calculation routine make such a difference? It's called exactly once per list item in both cases. And why is my expectation that the default sort (i.e. with no comparison block) should trounce other, non-default sorts completely unrealized here? Does sort have some nifty optimizations in 5.8?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://598664]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (3)
As of 2018-05-21 07:07 GMT
Find Nodes?
    Voting Booth?