[Elliot Gorokhovsky <elliot.gorokhov...@gmail.com>] > (Summary of results: my patch at https://bugs.python.org/issue28685 makes list.sort() 30-50% > faster in common cases, and at most 1.5% slower in the uncommon worst case.) > ...
Would someone please move the patch along? I expect it's my fault it's languished so long, since I'm probably the natural person to review it, but I've been buried under other stuff. But the patch doesn't change anything about the sorting algorithm itself - even shallow knowledge of how timsort works is irrelevant. It's just plugging in a different bottom-level object comparison _function_ when that appears valuable. I've said from the start that it's obvious (to me ;-) ) that it's an excellent tradeoff. At worst it adds one simple (pre)pass over the list doing C-level pointer equality comparisons. That's cheap. The worst-case damage is obviously small, the best-case gain is obviously large, and the best cases are almost certainly far more common than the worst cases in most code. In reviewing my own code, after it was fiddled to work under Python 3 there are no mixed-type lists that are ever sorted. There are lists with complex objects, but whenever those are sorted there's a `key=` argument that reduces the problem to sorting ints or tuples of builtin scalar types. I don't care about anyone else's code ;-) One subtle thing to look at: thread safety. IIRC, the patch plugged the comparison function into a file global. That's obviously hosed if multiple threads sort different kinds of lists simultaneously.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
