Here's a simple test program: from time import clock indices = [1] * 100000 def doit(): s = clock() i = 0 while i < 100000: "ab" < "cd" i += 1 f = clock() return f - s for i in xrange(10): print "%.3f" % doit() And here's output from 2.0, 2.1 and current CVS: C:\Code\python\dist\src\PCbuild>\python20\python timech.py 0.107 0.106 0.109 0.106 0.106 0.106 0.106 0.106 0.105 0.106 C:\Code\python\dist\src\PCbuild>\python21\python timech.py 0.118 0.118 0.117 0.118 0.117 0.118 0.117 0.118 0.117 0.118 C:\Code\python\dist\src\PCbuild>python timech.py 0.119 0.117 0.118 0.117 0.118 0.117 0.118 0.117 0.118 So "something happened" between 2.0 and 2.1 to slow this overall by 10%. string_compare hasn't changed, so rich comparisons are a good guess. Note that the more obvious timing loop obscures the issue: def doit(): s = clock() for i in indices: "ab" < "cd" f = clock() return f - s C:\Code\python\dist\src\PCbuild>\python20\python timech.py 0.070 0.069 0.069 0.070 0.069 0.069 0.069 0.070 0.069 0.069 C:\Code\python\dist\src\PCbuild>\python21\python timech.py 0.076 0.076 0.076 0.076 0.076 0.077 0.076 0.076 0.076 0.076 C:\Code\python\dist\src\PCbuild>python timech.py 0.069 0.070 0.070 0.069 0.069 0.070 0.070 0.069 0.070 0.069 for-loops are faster in current CVS than in 2.0 or 2.1, and that cancels out the comparison slowdown. If we try it with a type of comparison that avoids the richcmp machinery (int < int is special-cased in ceval), current CVS is actually faster than 2.0: def doit(): s = clock() for i in indices: 2 < 3 f = clock() return f - s C:\Code\python\dist\src\PCbuild>\python20\python timech.py 0.056 0.056 0.056 0.056 0.055 0.056 0.058 0.058 0.055 0.056 C:\Code\python\dist\src\PCbuild>\python21\python timech.py 0.059 0.059 0.059 0.060 0.060 0.059 0.059 0.060 0.059 0.059 C:\Code\python\dist\src\PCbuild>python timech.py 0.053 0.052 0.052 0.053 0.053 0.052 0.052 0.054 0.052 0.053 C:\Code\python\dist\src\PCbuild> This also shows that 2.1 was a bit more slothful than 2.0 for some reason other than richcmps. These were all done on a Win2K box; timings vary too much on a Win9x box to be useful. Anybody care to take a stab at making the new richcmp and/or coerce code ugly again? speed-isn't-pretty-but-then-guts-rarely-are-ly y'rs - tim
On Mon, May 14, 2001 at 04:12:44PM -0400, Tim Peters wrote:
... Anybody care to take a stab at making the new richcmp and/or coerce code ugly again?
speed-isn't-pretty-but-then-guts-rarely-are-ly y'rs - tim
Euh... isn't Guido's preference for cleanliness over speed? Cheers, -g -- Greg Stein, http://www.lyra.org/
speed-isn't-pretty-but-then-guts-rarely-are-ly y'rs - tim
Euh... isn't Guido's preference for cleanliness over speed?
Yeah, Tim & I have developed a nice good-cop-bad-cop routine about this. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Greg Stein
-
Guido van Rossum
-
Tim Peters