Second, your code seems to be uselessly complicated (and even sometimes somewhat awkward) for what you want to do. Cascading sub calls may suffice to ruin the results of a benchmark.
Third, unless you are writing an article on Schwartzian Transform (ST) or a book, it does not make very much sense to compare regular sort with ST sort on a theoretical dataset like that. The essence of ST is caching the data used for the comparison in the sort. Caching has a cost and is worthwhile only if this cost is small compared to the saving induced by not having to recalculate many times the data used for comparisons in the sort.
So, unless you are just trying to make a theoretical study on ST sort vs. regular sort, the exercise is not very useful. Or, rather, let's say that it will probably not be possible to extrapolate the results you're gonna get to a real life scenario, because the CPU operations that you want to save with ST will not be similar in terms of time consumed, and/or the data samples will not have the same size (large datasets will usually give a slightly better advantage to ST sort, because the number of comparisons to be made grows faster than the size of the dataset). So, in brief, if you really want to benchmark ST sort versus regular sort, you do it with a realistic data sample of your use case.
Having said all that, I am quite regularly using ST (or GRT) when the data for comparison is not immediately available in the dataset and needs some form of computation, not necessarily for performance reasons, but because I find it cleaner and simpler than having to explicitly declare and populate temporary arrays. Also, I like the "functional programing" (Lisp-like) aspect of the ST sort. I love the ability of Perl to do this sort of things.
In reply to Re: Benchmark Schwartzian Transform
by Laurent_R
in thread Benchmark Schwartzian Transform
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |