]> granicus.if.org Git - python/commit
Cleanup yielding a small speed boost: before rich comparisons were
authorTim Peters <tim.peters@gmail.com>
Fri, 19 Jul 2002 03:30:57 +0000 (03:30 +0000)
committerTim Peters <tim.peters@gmail.com>
Fri, 19 Jul 2002 03:30:57 +0000 (03:30 +0000)
commita8c974c157c8f4e2b0c16b9be638db54748aa12b
treedbcc99af3d14781dda91240d0029d1992a0a3eee
parent3b01a1217f3bbde4c40e08e2e64f268410f6fdcf
Cleanup yielding a small speed boost:  before rich comparisons were
introduced, list.sort() was rewritten to use only the "< or not <?"
distinction.  After rich comparisons were introduced, docompare() was
fiddled to translate a Py_LT Boolean result into the old "-1 for <,
0 for ==, 1 for >" flavor of outcome, and the sorting code was left
alone.  This left things more obscure than they should be, and turns
out it also cost measurable cycles.

So:  The old CMPERROR novelty is gone.  docompare() is renamed to islt(),
and now has the same return conditinos as PyObject_RichCompareBool.  The
SETK macro is renamed to ISLT, and is even weirder than before (don't
complain unless you want to maintain the sort code <wink>).

Overall, this yields a 1-2% speedup in the usual (no explicit function
passed to list.sort()) case when sorting arrays of floats (as sortperf.py
does).  The boost is higher for arrays of ints.
Objects/listobject.c