|XP is just a number|
Re^9: RFC:A brief tutorial on Perl's native sorting facilities.by jdporter (Canon)
|on Feb 07, 2007 at 01:19 UTC||Need Help??|
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
Could that be the source of the difference in results?
To check this possibility, I made my key calculation more expensive:
(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?