Benchmarking all prelst functions:
The official ruling has been challenged.
Changing quoted lambda's to optimized
(functions) produced a different photo finish.
EDIT:Lee, I did not raise the ceiling, but did so after you pointed it out.
I removed my results (because of it's innacuracy), and
The top competitors in my own tests were quite supprising. This is probably due to the lack of overhead that's required for iterative methods.
I was able to get 10,001 length lists to run for all functions..
The tests are fantastic and show me that optimization is important, but also that the least verbose isn't always the bestest under heavy loads of bulk data processing.
Overhead of a function also doesn't mean it's the worst either. Evidence by the likes of the MergeSort algorithm, which uses three times the memory as, say, a JSort or InsertSort. At one million entries MergeSort excels while Jsort kills MergeSort below 50,000 (of course this depends further on your implementation methods and even comilers).
The different bench test results vary from the method of testing and the data set as we've seen through the multiple user results. This thread has shown me that your data set just needs to be considered and the generous contributions tested yourself.
Here's the suprising results I got out of 10,001 length list, contradicts other user's results. I did not expect function optimized lambda's to perform so poorly. I remember a post from long ago that explained (in autolisp) why it's one way or the other, but I remember neither the lesson of the author nor where I read it.
n=10,001
Elapsed milliseconds / relative speed for 32768 iteration(s):
(LM:PRELST3 N L)...............1217 / 684.78 <fastest>
(CAB:PRELST L N)...............1232 / 676.44
(CH:PRELST N L 1.0e-008).......1295 / 643.53
(LM:PRELST5 N L)...............1295 / 643.53
(MR:PRELST2 L N)...............1310 / 636.16
(MR:PRELST3 L N)...............1326 / 628.49
(LM:PRELST4 N L)...............1544 / 539.75
(LM:PRELST2 N L).............180992 / 4.60
(LM:PRELST1 N L).............343389 / 2.43
(PH:PREF L N)................825308 / 1.01
(MR:PRELST1 L N).............833373 / 1.00 <slowest>
Under a presumption that garabage collection could be skewing the results of functions that were later in the test, I switched the order of execution for the test, and the same results were obtained.
As far as I can see ((now)), that there is not just one
winner, rather there were 7. I've enjoyed this thread emensly. Looking forward to see if there's' any basis of what I noticed with lambda.
They were compiled.