Re: Benchmark, -s versus schwartzian

[Jenda]

Schwartzian transformation is quicker only if the sort criteria is complex enough. ST makes sure the computation is only done N times instead of O(N*log(N)) times at the expense of creating a temporary array of two-item arrays containing the original values and the computed results. If the overhead of this AoA is bigger than the gain obtained by decreasing the number of "complex computations" ST is slower than the ordinary sort.

I think the -s is not a well chosen example for ST. Whether you actually gain or loose by using ST depends on too many things, the disk speed and cache size, the OS, the number of files in the directory, the speed of your CPU, the amount and speed of your memory, ...

[merlyn]

Yes, the -s example is a simple example, but doesn't necessarily highlight the ST. The point of the section is to talk about the expense of the comparison function, and one possible solution. I chose -s, because it's easy to talk about, and the ST, because it's the most straightforward general solution. Certainly, in specialized cases, a simple array cache or hash cache or GRT might be better.

In a tutorial, I'm constantly weighing how much or how little to say to accomplish some level of understanding for the tasks at hand. It's trickier than it looks, as anyone who has written training materials can confirm.

[Anonymous Monk]

I'd say that in the general case, GRT will be the fastest solution. If the list is large enough, the bottleneck will be in the sort function, and since the GRT has the simplest sort function possible (namely, the default one), it will outperform anything else.

[merlyn]

By "general", I mean "mortal people can work out a solution for all complex sort criterion". You have to be a frickin' genius to work out a single string for the GRT sometimes. The ST in comparison is always straightforward: construct a list of your sortable keys for a given input item.