Author rhettinger
Recipients collinwinter, pitrou, rhettinger, stutzbach, tim.peters
Date 2010-09-21.20:43:54
SpamBayes Score 1.9255e-06
Marked as misclassified No
Message-id <1285101836.54.0.610638995071.issue9915@psf.upfronthosting.co.za>
In-reply-to
Content
Conceptually, this is a reasonable approach.  

I originally put in the sortwrapper as a straight-forward technique of tackling the 2.x API which allowed a key-function, or a cmp-function, or both, or neither.   IOW, the original motivation is now gone.  The only remaining advantage of the sortwrapper is that it is independent of the main code for the timsort, so both are more readable and maintainable in their current form.

I've only had a cursory look at the patch.  A couple of thoughts:

* The memmove, memcpy functions are tricky to time because of varying performance across various architectures and libraries.  Code like "*dest++ = *pb++;" is hard to beat, especially for short runs.

* Is the code slower for the common case where a key function is not provided?  The patch seems to add a level of indirection throughout the code (lots of "lo.values" instead of just "lo").

* A more extensive timing suite would be helpful; the ones listed in the first post are simplistic.
History
Date User Action Args
2010-09-21 20:43:56rhettingersetrecipients: + rhettinger, tim.peters, collinwinter, pitrou, stutzbach
2010-09-21 20:43:56rhettingersetmessageid: <1285101836.54.0.610638995071.issue9915@psf.upfronthosting.co.za>
2010-09-21 20:43:55rhettingerlinkissue9915 messages
2010-09-21 20:43:54rhettingercreate