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]
[download]

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 ) )
[download]

(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?