[issue9915] speeding up sorting with a key

Raymond Hettinger report at bugs.python.org
Tue Sep 21 22:43:56 CEST 2010


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________


More information about the Python-bugs-list mailing list