current problems that should be fixed before release (2.6)
Below are the problems I found that have not been fixed at r65995 on trunk (2.6). There will be a separate mail for the 3.0 problems. I've done the following: * built in debug and opt mode (gcc 4.1.2) fixing the important warnings * run all the tests in both modes * run all the tests (except test_logging and test_ssl) under valgrind 3.3.1 fixing the problems * run failmalloc (1.0) on startup for the first 4000 allocations fixing most problems * run pychecker 0.8.18 over the stdlib (Lib/*.py, Lib/[bcdelhjmswx]*/*.py) Can someone run purify on windows over 2.6? Can someone (else) compare performance of 2.5, 2.6, and 3.0? pychecker reported problems: Lib/gzip.py:114: Using property (filename) in classic class GzipFile may not work Lib/io.py:1394: No module attribute (device_encoding) found - device_encoding access is protected, but I don't see where it can be set Lib/sched.py:122: Using property (queue) in classic class scheduler may not work Lib/tempfile.py:535: Using property (closed) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:539: Using property (encoding) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:553: Using property (mode) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:557: Using property (name) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:561: Using property (newlines) in classic class SpooledTemporaryFile may not work Lib/tempfile.py:580: Using property (softspace) in classic class SpooledTemporaryFile may not work Lib/multiprocessing/connection.py:95: No global (PipeListener) found Lib/multiprocessing/connection.py:132: No global (PipeClient) found - both of the Pipe classes are defined only for windows. I don't see a similar def for Unix. Lib/multiprocessing/connection.py:378: No global (AuthenticationError) found I haven't looked into the property complaint to see how bad it is. test_bsddb3 is failing on several 2.6 buildbots. test_bsddb3 leaks 80 references. Results of valgrind 3.3.1 on Ubuntu 6.10 amd64, gcc 4.1.2 (prerelease): Uninitialized memory reads: No problems in python code. Though it's possible there are errors in ctypes. I'm ignoring those reports due to a problem in dlopen. Wild memory writes: No problems in python code. Memory leaks: No major problems. However, it seems that there are a bunch of little leaks when forking a process. I haven't determined if these are real problems or not. There is one memory leak in ctypes (sorry no real useful information): 44 bytes in 1 blocks are definitely lost in loss record 43 of 191 malloc (vg_replace_malloc.c:207) resize (callproc.c:1733) It seems to always leak 44 bytes n
Neal> Lib/gzip.py:114: Using property (filename) in classic class GzipFile Neal> may not work Seems shallow. Just inherit from object. Neal> Lib/sched.py:122: Using property (queue) in classic class scheduler Neal> may not work Ditto. Neal> Lib/tempfile.py:535: Using property (closed) in classic class Neal> SpooledTemporaryFile may not work ... Ditto. Neal> Lib/multiprocessing/connection.py:378: No global (AuthenticationError) found This is defined in the __init__ module of the package. Is it accessible from connection.py without further import? (My guess would be no.) A slight code rearrangement or adding imports at the point of the raise statements probably fixes that. Neal> I haven't looked into the property complaint to see how bad it is. I'm testing out the inherit-from-object fixes now. Will report back later. Skip
me> Seems shallow. Just inherit from object. ... me> I'm testing out the inherit-from-object fixes now. They all passed. Here's the patch: http://bugs.python.org/issue3658 In addition, I get these two test failures on trunk: % ./python.exe ../Lib/test/regrtest.py test_distutils test_multiprocessing test_distutils test test_distutils failed -- Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/distutils/tests/test_build_ext.py", line 23, in setUp shutil.copy(xx_c, self.tmp_dir) File "/Users/skip/src/python/trunk/Lib/shutil.py", line 88, in copy copyfile(src, dst) File "/Users/skip/src/python/trunk/Lib/shutil.py", line 52, in copyfile fsrc = open(src, 'rb') IOError: [Errno 2] No such file or directory: '/Users/skip/src/python/trunk/regular/Modules/xxmodule.c' test_multiprocessing test test_multiprocessing failed -- Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_multiprocessing.py", line 1223, in test_connection res = conn.recv_bytes_into(buffer) TypeError: argument 1 must be pinned buffer, not bytearray 2 tests failed: test_distutils test_multiprocessing The former is almost certainly because I'm building in a subdirectory of my trunk sandbox. (Doesn't anybody else build that way these days? I routinely encounter problems with this setup.) Looks like distutils.sysconfig.project_base is set incorrectly: % ./python.exe Python 2.6b3+ (trunk:66009M, Aug 24 2008, 07:17:12) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> import sys >>> project_base = os.path.dirname(os.path.abspath(sys.executable)) >>> project_base '/Users/skip/src/python/trunk/regular' I think project_base should be /Users/skip/src/python/trunk, not .../trunk/regular. Skip
Neal Norwitz <nnorwitz <at> gmail.com> writes:
Can someone (else) compare performance of 2.5, 2.6, and 3.0?
Tests done on a 32-bit Linux installation on an Athlon 3600+ X2. Compiled with gcc in UCS2 mode. pystone ------- - 2.5: 43859.6 pystones/second - 2.6: 42016.8 pystones/second - 3.0: 38759.7 pystones/second richards.py ----------- (roughly, richards is an object-oriented method-calling benchmark) - 2.5: 770.54 ms per iteration - 2.6: 572.84 ms per iteration - 3.0: 566.69 ms per iteration stringbench ----------- - 2.5: unicode: 265.84 s / bytes: 180.50 s - 2.6: unicode: 256.22 s / bytes: 184.45 s - 3.0: unicode: 248.07 s / bytes: not tested pybench: 2.6 vs. 2.5 -------------------- "this" is 2.6, "other" is 2.5. Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 177ms 181ms -2.2% 178ms 182ms -2.1% BuiltinMethodLookup: 157ms 177ms -11.1% 158ms 177ms -11.0% CompareFloats: 171ms 171ms -0.3% 171ms 171ms -0.3% CompareFloatsIntegers: 158ms 162ms -2.1% 160ms 167ms -4.8% CompareIntegers: 208ms 208ms -0.0% 209ms 209ms -0.3% CompareInternedStrings: 189ms 183ms +3.4% 189ms 184ms +2.7% CompareLongs: 154ms 154ms -0.2% 154ms 154ms -0.2% CompareStrings: 162ms 159ms +1.7% 163ms 159ms +2.5% CompareUnicode: 144ms 149ms -3.6% 144ms 152ms -5.0% ComplexPythonFunctionCalls: 173ms 242ms -28.5% 176ms 243ms -27.6% ConcatStrings: 196ms 198ms -0.9% 203ms 200ms +1.4% ConcatUnicode: 153ms 151ms +1.5% 155ms 157ms -1.5% CreateInstances: 172ms 169ms +1.5% 173ms 170ms +1.4% CreateNewInstances: 131ms 148ms -11.6% 132ms 151ms -12.2% CreateStringsWithConcat: 209ms 206ms +1.4% 209ms 208ms +0.8% CreateUnicodeWithConcat: 128ms 124ms +3.7% 129ms 124ms +3.4% DictCreation: 115ms 149ms -22.8% 116ms 150ms -22.8% DictWithFloatKeys: 208ms 207ms +0.4% 208ms 208ms +0.0% DictWithIntegerKeys: 173ms 173ms -0.0% 174ms 173ms +0.5% DictWithStringKeys: 162ms 162ms -0.1% 162ms 162ms +0.1% ForLoops: 181ms 181ms -0.2% 181ms 182ms -0.2% IfThenElse: 169ms 168ms +0.2% 169ms 169ms -0.2% ListSlicing: 109ms 108ms +0.2% 109ms 109ms +0.1% NestedForLoops: 198ms 197ms +0.2% 198ms 197ms +0.1% NormalClassAttribute: 176ms 172ms +2.0% 176ms 173ms +1.7% NormalInstanceAttribute: 162ms 161ms +1.0% 163ms 161ms +1.1% PythonFunctionCalls: 161ms 151ms +6.6% 162ms 153ms +6.0% PythonMethodCalls: 188ms 189ms -0.7% 189ms 193ms -2.0% Recursion: 235ms 230ms +2.2% 236ms 233ms +1.2% SecondImport: 113ms 114ms -1.0% 115ms 115ms +0.0% SecondPackageImport: 120ms 116ms +3.6% 120ms 117ms +2.9% SecondSubmoduleImport: 154ms 146ms +6.0% 156ms 148ms +5.7% SimpleComplexArithmetic: 163ms 151ms +8.3% 163ms 151ms +8.6% SimpleDictManipulation: 177ms 173ms +2.6% 180ms 174ms +3.2% SimpleFloatArithmetic: 169ms 164ms +3.0% 169ms 166ms +2.2% SimpleIntFloatArithmetic: 153ms 152ms +1.2% 156ms 153ms +1.8% SimpleIntegerArithmetic: 156ms 152ms +2.5% 156ms 153ms +2.0% SimpleListManipulation: 156ms 158ms -1.0% 157ms 158ms -0.5% SimpleLongArithmetic: 159ms 150ms +6.1% 161ms 151ms +6.3% SmallLists: 156ms 154ms +1.1% 160ms 155ms +3.0% SmallTuples: 156ms 155ms +0.4% 157ms 156ms +0.8% SpecialClassAttribute: 173ms 172ms +0.6% 173ms 172ms +0.7% SpecialInstanceAttribute: 202ms 198ms +2.4% 203ms 199ms +2.2% StringMappings: 164ms 170ms -3.2% 165ms 171ms -3.9% StringPredicates: 160ms 185ms -13.6% 160ms 186ms -13.9% StringSlicing: 169ms 178ms -5.3% 174ms 180ms -3.4% TryExcept: 181ms 184ms -1.5% 181ms 184ms -1.5% TryFinally: 157ms 158ms -0.3% 159ms 161ms -1.2% TryRaiseExcept: 183ms 122ms +49.6% 184ms 124ms +48.2% TupleSlicing: 142ms 140ms +1.5% 144ms 141ms +2.0% UnicodeMappings: 198ms 190ms +4.1% 198ms 190ms +4.1% UnicodePredicates: 157ms 175ms -10.2% 157ms 176ms -10.6% UnicodeProperties: 161ms 161ms +0.1% 162ms 170ms -5.0% UnicodeSlicing: 148ms 153ms -3.3% 151ms 155ms -2.6% WithFinally: 191ms 203ms -5.9% 193ms 208ms -7.5% WithRaiseExcept: 151ms 160ms -5.8% 152ms 167ms -9.0% ------------------------------------------------------------------------------- Totals: 9287ms 9363ms -0.8% 9351ms 9455ms -1.1% pybench: 3.0 ------------ Not entirely comparable with the above since some tests disappeared. Test minimum average operation overhead ------------------------------------------------------------------------------- BuiltinFunctionCalls: 134ms 134ms 0.26us 0.631ms BuiltinMethodLookup: 127ms 127ms 0.12us 0.738ms CompareFloats: 174ms 174ms 0.14us 0.845ms CompareFloatsIntegers: 274ms 274ms 0.30us 0.630ms CompareIntegers: 277ms 277ms 0.15us 1.272ms CompareInternedStrings: 261ms 261ms 0.17us 3.201ms CompareLongs: 162ms 162ms 0.15us 0.736ms CompareStrings: 171ms 173ms 0.17us 2.188ms ComplexPythonFunctionCalls: 172ms 178ms 0.89us 1.073ms ConcatStrings: 260ms 273ms 0.55us 1.222ms CreateInstances: 178ms 178ms 1.59us 0.944ms CreateNewInstances: 133ms 135ms 1.61us 0.759ms CreateStringsWithConcat: 253ms 256ms 0.26us 2.127ms DictCreation: 118ms 118ms 0.29us 0.845ms DictWithFloatKeys: 207ms 215ms 0.24us 1.593ms DictWithIntegerKeys: 174ms 176ms 0.15us 2.132ms DictWithStringKeys: 158ms 158ms 0.13us 2.127ms ForLoops: 188ms 188ms 7.51us 0.097ms IfThenElse: 212ms 212ms 0.16us 1.597ms ListSlicing: 111ms 111ms 7.96us 0.165ms NestedForLoops: 218ms 220ms 0.15us 0.001ms NormalClassAttribute: 339ms 340ms 0.28us 1.111ms NormalInstanceAttribute: 186ms 186ms 0.16us 1.116ms PythonFunctionCalls: 156ms 158ms 0.48us 0.633ms PythonMethodCalls: 200ms 201ms 0.89us 0.374ms Recursion: 259ms 260ms 5.21us 1.059ms SecondImport: 128ms 128ms 1.28us 0.417ms SecondPackageImport: 140ms 143ms 1.43us 0.417ms SecondSubmoduleImport: 200ms 200ms 2.00us 0.417ms SimpleComplexArithmetic: 142ms 144ms 0.16us 0.844ms SimpleDictManipulation: 280ms 285ms 0.24us 1.059ms SimpleFloatArithmetic: 161ms 161ms 0.12us 1.275ms SimpleIntFloatArithmetic: 199ms 213ms 0.16us 1.272ms SimpleIntegerArithmetic: 200ms 209ms 0.16us 1.301ms SimpleListManipulation: 165ms 166ms 0.14us 1.379ms SimpleLongArithmetic: 132ms 137ms 0.21us 0.630ms SmallLists: 188ms 191ms 0.28us 0.844ms SmallTuples: 197ms 199ms 0.37us 0.951ms SpecialClassAttribute: 534ms 535ms 0.45us 1.121ms SpecialInstanceAttribute: 185ms 186ms 0.15us 1.125ms StringMappings: 471ms 471ms 1.87us 0.884ms StringPredicates: 190ms 191ms 0.27us 4.315ms StringSlicing: 285ms 290ms 0.52us 1.881ms TryExcept: 182ms 182ms 0.08us 1.663ms TryFinally: 134ms 136ms 0.85us 0.882ms TryRaiseExcept: 137ms 138ms 2.15us 0.885ms TupleSlicing: 202ms 204ms 0.78us 0.110ms WithFinally: 185ms 188ms 1.18us 0.881ms WithRaiseExcept: 274ms 275ms 3.44us 1.105ms ------------------------------------------------------------------------------- Totals: 10011ms 10120ms
Thanks Antoine! On Sun, Aug 24, 2008 at 5:58 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
So 3.0 is about 10% slower than 2.x. Given all the changes, that doesn't seem too bad. Though, see below. It looks like at least class attribute lookup is much, much slower. Can you investigate some of these and file bugs as appropriate?
I'm a little concerned about why the big change here. Though if I'm reading this right it's a speed up...or am I just being optimistic? The only things I remember that changed between 2.5 and 2.6 that might affect this (without looking at any code) were: 1) Armin's method caching, and 2) the slowdown to isinstance/issubclass which has a release blocker: http://bugs.python.org/issue2534 Can you dig into this and see what caused the slowdown?
Hopefully anything >10% is a real change and not just noise.
Maybe explained by Armin's patch.
Maybe explained by Armin's patch.
Maybe explained by Armin's patch.
Why? What changed?
Maybe explained by Armin's patch.
Whoa, that's a big slowdown. I wonder if it's consistent?
?
Much slower, but probably due to switch from int -> long. There could be potential for optimizing this case.
CompareIntegers: 277ms 277ms 0.15us 1.272ms
That's really slow!
CompareInternedStrings: 261ms 261ms 0.17us 3.201ms
Much slower, but probably str -> unicode conversion.
CompareLongs: 162ms 162ms 0.15us 0.736ms
But this is comparable to 2.x. I don't understand that?
This is much slower in 3.0, even taking into account str -> unicode?
Slower?
Over twice as slow?
Slower. str -> unicode?
~4x slower!
SpecialInstanceAttribute: 185ms 186ms 0.15us 1.125ms StringMappings: 471ms 471ms 1.87us 0.884ms
~3X slower.
Slower.
Hi,
So 3.0 is about 10% slower than 2.x. Given all the changes, that doesn't seem too bad.
Yes, I think it's rather good.
Yes, it is a speed up. It is thanks to Armin's method cache.
ComplexPythonFunctionCalls: 173ms 242ms -28.5% 176ms 243ms -27.6%
Maybe explained by Armin's patch.
Actually it is I and Raymond's patch speeding up function calls with named parameters.
DictCreation: 115ms 149ms -22.8% 116ms 150ms -22.8%
Why? What changed?
The opcode sequence for creation of dict literals has been optimized.
StringPredicates: 160ms 185ms -13.6% 160ms 186ms -13.9%
Maybe explained by Armin's patch.
I don't think so.
TryRaiseExcept: 183ms 122ms +49.6% 184ms 124ms +48.2%
Whoa, that's a big slowdown. I wonder if it's consistent?
Yes, I can definitely reproduce it.
UnicodePredicates: 157ms 175ms -10.2% 157ms 176ms -10.6%
?
Probably thanks to the speedup in whitespace detection.
Well honestly you don't often compare different types. I think the most common exception to this rule would be None vs. non-None.
I think CompareIntegers and CompareLongs aren't the same tests exactly, although they test the same operations. I've already proposed a patch to speedup comparisons in py3k: http://bugs.python.org/issue3106
ConcatStrings: 260ms 273ms 0.55us 1.222ms
This is much slower in 3.0, even taking into account str -> unicode?
The number of rounds is not the same (60000 for 2.6 with unicode, 100000 for 3.0 with str). It should probably be fixed.
IfThenElse: 212ms 212ms 0.16us 1.597ms
Slower?
It is based on integer comparisons though.
NormalClassAttribute: 339ms 340ms 0.28us 1.111ms
Over twice as slow?
Yes, should be investigated.
SimpleDictManipulation: 280ms 285ms 0.24us 1.059ms
Slower. str -> unicode?
No, there are just integers.
SpecialClassAttribute: 534ms 535ms 0.45us 1.121ms
~4x slower!
Should be investigated as well.
StringMappings: 471ms 471ms 1.87us 0.884ms
~3X slower.
It's normal. This test measures functions like upper(), etc., which are much expensive using the full unicode database than when doing a straight lookup in a 256-entry table.
Yes, the new exception semantics have a cost. Regards Antoine.
Antoine Pitrou schrieb:
Hi,
pystone ------- - 2.5: 43859.6 pystones/second - 2.6: 42016.8 pystones/second - 3.0: 38759.7 pystones/second
Well, pystone really doesn't test much of what causes the largest slowdowns in 3.0... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Mon, 25 Aug 2008 05:04:16 am Antoine Pitrou wrote:
Surely the most common None vs non-None comparison would be the "is" operator, which I hope remains fast. I don't know about other people, but I often compare floats with ints. Here's a contrived example: x = some_float() if x == -1: return -2 else: return (x**2-1)/(x+1) I suppose it's no hardship to start writing float literals instead of int literals, if needed. -- Steven
On 2008-08-24 21:04, Antoine Pitrou wrote:
That's a huge slow-down compared to 2.5. Are there any obvious reasons for this ? Has the exception handling mechanism changed that much between 2.5 and 2.6 ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 25 2008)
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
M.-A. Lemburg <mal <at> egenix.com> writes:
I've looked at it a bit and I think it's because of the issubclass()/isinstance() slowdown (which itself is due to ABCs). If I apply the patch in http://bugs.python.org/issue2534, the exception handling slowdown seems to disappear.
Antoine Pitrou <solipsis <at> pitrou.net> writes:
[...]
It turns out that these two slowdowns are due to classes always being new-style in py3k. Indeed, if I add "__metaclass__ = type" at the beginning of Tools/pybench/Lookups.py, 2.6 becomes as slow as 3.0. Regards Antoine.
Neal> Lib/gzip.py:114: Using property (filename) in classic class GzipFile Neal> may not work Seems shallow. Just inherit from object. Neal> Lib/sched.py:122: Using property (queue) in classic class scheduler Neal> may not work Ditto. Neal> Lib/tempfile.py:535: Using property (closed) in classic class Neal> SpooledTemporaryFile may not work ... Ditto. Neal> Lib/multiprocessing/connection.py:378: No global (AuthenticationError) found This is defined in the __init__ module of the package. Is it accessible from connection.py without further import? (My guess would be no.) A slight code rearrangement or adding imports at the point of the raise statements probably fixes that. Neal> I haven't looked into the property complaint to see how bad it is. I'm testing out the inherit-from-object fixes now. Will report back later. Skip
me> Seems shallow. Just inherit from object. ... me> I'm testing out the inherit-from-object fixes now. They all passed. Here's the patch: http://bugs.python.org/issue3658 In addition, I get these two test failures on trunk: % ./python.exe ../Lib/test/regrtest.py test_distutils test_multiprocessing test_distutils test test_distutils failed -- Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/distutils/tests/test_build_ext.py", line 23, in setUp shutil.copy(xx_c, self.tmp_dir) File "/Users/skip/src/python/trunk/Lib/shutil.py", line 88, in copy copyfile(src, dst) File "/Users/skip/src/python/trunk/Lib/shutil.py", line 52, in copyfile fsrc = open(src, 'rb') IOError: [Errno 2] No such file or directory: '/Users/skip/src/python/trunk/regular/Modules/xxmodule.c' test_multiprocessing test test_multiprocessing failed -- Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_multiprocessing.py", line 1223, in test_connection res = conn.recv_bytes_into(buffer) TypeError: argument 1 must be pinned buffer, not bytearray 2 tests failed: test_distutils test_multiprocessing The former is almost certainly because I'm building in a subdirectory of my trunk sandbox. (Doesn't anybody else build that way these days? I routinely encounter problems with this setup.) Looks like distutils.sysconfig.project_base is set incorrectly: % ./python.exe Python 2.6b3+ (trunk:66009M, Aug 24 2008, 07:17:12) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> import sys >>> project_base = os.path.dirname(os.path.abspath(sys.executable)) >>> project_base '/Users/skip/src/python/trunk/regular' I think project_base should be /Users/skip/src/python/trunk, not .../trunk/regular. Skip
Neal Norwitz <nnorwitz <at> gmail.com> writes:
Can someone (else) compare performance of 2.5, 2.6, and 3.0?
Tests done on a 32-bit Linux installation on an Athlon 3600+ X2. Compiled with gcc in UCS2 mode. pystone ------- - 2.5: 43859.6 pystones/second - 2.6: 42016.8 pystones/second - 3.0: 38759.7 pystones/second richards.py ----------- (roughly, richards is an object-oriented method-calling benchmark) - 2.5: 770.54 ms per iteration - 2.6: 572.84 ms per iteration - 3.0: 566.69 ms per iteration stringbench ----------- - 2.5: unicode: 265.84 s / bytes: 180.50 s - 2.6: unicode: 256.22 s / bytes: 184.45 s - 3.0: unicode: 248.07 s / bytes: not tested pybench: 2.6 vs. 2.5 -------------------- "this" is 2.6, "other" is 2.5. Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 177ms 181ms -2.2% 178ms 182ms -2.1% BuiltinMethodLookup: 157ms 177ms -11.1% 158ms 177ms -11.0% CompareFloats: 171ms 171ms -0.3% 171ms 171ms -0.3% CompareFloatsIntegers: 158ms 162ms -2.1% 160ms 167ms -4.8% CompareIntegers: 208ms 208ms -0.0% 209ms 209ms -0.3% CompareInternedStrings: 189ms 183ms +3.4% 189ms 184ms +2.7% CompareLongs: 154ms 154ms -0.2% 154ms 154ms -0.2% CompareStrings: 162ms 159ms +1.7% 163ms 159ms +2.5% CompareUnicode: 144ms 149ms -3.6% 144ms 152ms -5.0% ComplexPythonFunctionCalls: 173ms 242ms -28.5% 176ms 243ms -27.6% ConcatStrings: 196ms 198ms -0.9% 203ms 200ms +1.4% ConcatUnicode: 153ms 151ms +1.5% 155ms 157ms -1.5% CreateInstances: 172ms 169ms +1.5% 173ms 170ms +1.4% CreateNewInstances: 131ms 148ms -11.6% 132ms 151ms -12.2% CreateStringsWithConcat: 209ms 206ms +1.4% 209ms 208ms +0.8% CreateUnicodeWithConcat: 128ms 124ms +3.7% 129ms 124ms +3.4% DictCreation: 115ms 149ms -22.8% 116ms 150ms -22.8% DictWithFloatKeys: 208ms 207ms +0.4% 208ms 208ms +0.0% DictWithIntegerKeys: 173ms 173ms -0.0% 174ms 173ms +0.5% DictWithStringKeys: 162ms 162ms -0.1% 162ms 162ms +0.1% ForLoops: 181ms 181ms -0.2% 181ms 182ms -0.2% IfThenElse: 169ms 168ms +0.2% 169ms 169ms -0.2% ListSlicing: 109ms 108ms +0.2% 109ms 109ms +0.1% NestedForLoops: 198ms 197ms +0.2% 198ms 197ms +0.1% NormalClassAttribute: 176ms 172ms +2.0% 176ms 173ms +1.7% NormalInstanceAttribute: 162ms 161ms +1.0% 163ms 161ms +1.1% PythonFunctionCalls: 161ms 151ms +6.6% 162ms 153ms +6.0% PythonMethodCalls: 188ms 189ms -0.7% 189ms 193ms -2.0% Recursion: 235ms 230ms +2.2% 236ms 233ms +1.2% SecondImport: 113ms 114ms -1.0% 115ms 115ms +0.0% SecondPackageImport: 120ms 116ms +3.6% 120ms 117ms +2.9% SecondSubmoduleImport: 154ms 146ms +6.0% 156ms 148ms +5.7% SimpleComplexArithmetic: 163ms 151ms +8.3% 163ms 151ms +8.6% SimpleDictManipulation: 177ms 173ms +2.6% 180ms 174ms +3.2% SimpleFloatArithmetic: 169ms 164ms +3.0% 169ms 166ms +2.2% SimpleIntFloatArithmetic: 153ms 152ms +1.2% 156ms 153ms +1.8% SimpleIntegerArithmetic: 156ms 152ms +2.5% 156ms 153ms +2.0% SimpleListManipulation: 156ms 158ms -1.0% 157ms 158ms -0.5% SimpleLongArithmetic: 159ms 150ms +6.1% 161ms 151ms +6.3% SmallLists: 156ms 154ms +1.1% 160ms 155ms +3.0% SmallTuples: 156ms 155ms +0.4% 157ms 156ms +0.8% SpecialClassAttribute: 173ms 172ms +0.6% 173ms 172ms +0.7% SpecialInstanceAttribute: 202ms 198ms +2.4% 203ms 199ms +2.2% StringMappings: 164ms 170ms -3.2% 165ms 171ms -3.9% StringPredicates: 160ms 185ms -13.6% 160ms 186ms -13.9% StringSlicing: 169ms 178ms -5.3% 174ms 180ms -3.4% TryExcept: 181ms 184ms -1.5% 181ms 184ms -1.5% TryFinally: 157ms 158ms -0.3% 159ms 161ms -1.2% TryRaiseExcept: 183ms 122ms +49.6% 184ms 124ms +48.2% TupleSlicing: 142ms 140ms +1.5% 144ms 141ms +2.0% UnicodeMappings: 198ms 190ms +4.1% 198ms 190ms +4.1% UnicodePredicates: 157ms 175ms -10.2% 157ms 176ms -10.6% UnicodeProperties: 161ms 161ms +0.1% 162ms 170ms -5.0% UnicodeSlicing: 148ms 153ms -3.3% 151ms 155ms -2.6% WithFinally: 191ms 203ms -5.9% 193ms 208ms -7.5% WithRaiseExcept: 151ms 160ms -5.8% 152ms 167ms -9.0% ------------------------------------------------------------------------------- Totals: 9287ms 9363ms -0.8% 9351ms 9455ms -1.1% pybench: 3.0 ------------ Not entirely comparable with the above since some tests disappeared. Test minimum average operation overhead ------------------------------------------------------------------------------- BuiltinFunctionCalls: 134ms 134ms 0.26us 0.631ms BuiltinMethodLookup: 127ms 127ms 0.12us 0.738ms CompareFloats: 174ms 174ms 0.14us 0.845ms CompareFloatsIntegers: 274ms 274ms 0.30us 0.630ms CompareIntegers: 277ms 277ms 0.15us 1.272ms CompareInternedStrings: 261ms 261ms 0.17us 3.201ms CompareLongs: 162ms 162ms 0.15us 0.736ms CompareStrings: 171ms 173ms 0.17us 2.188ms ComplexPythonFunctionCalls: 172ms 178ms 0.89us 1.073ms ConcatStrings: 260ms 273ms 0.55us 1.222ms CreateInstances: 178ms 178ms 1.59us 0.944ms CreateNewInstances: 133ms 135ms 1.61us 0.759ms CreateStringsWithConcat: 253ms 256ms 0.26us 2.127ms DictCreation: 118ms 118ms 0.29us 0.845ms DictWithFloatKeys: 207ms 215ms 0.24us 1.593ms DictWithIntegerKeys: 174ms 176ms 0.15us 2.132ms DictWithStringKeys: 158ms 158ms 0.13us 2.127ms ForLoops: 188ms 188ms 7.51us 0.097ms IfThenElse: 212ms 212ms 0.16us 1.597ms ListSlicing: 111ms 111ms 7.96us 0.165ms NestedForLoops: 218ms 220ms 0.15us 0.001ms NormalClassAttribute: 339ms 340ms 0.28us 1.111ms NormalInstanceAttribute: 186ms 186ms 0.16us 1.116ms PythonFunctionCalls: 156ms 158ms 0.48us 0.633ms PythonMethodCalls: 200ms 201ms 0.89us 0.374ms Recursion: 259ms 260ms 5.21us 1.059ms SecondImport: 128ms 128ms 1.28us 0.417ms SecondPackageImport: 140ms 143ms 1.43us 0.417ms SecondSubmoduleImport: 200ms 200ms 2.00us 0.417ms SimpleComplexArithmetic: 142ms 144ms 0.16us 0.844ms SimpleDictManipulation: 280ms 285ms 0.24us 1.059ms SimpleFloatArithmetic: 161ms 161ms 0.12us 1.275ms SimpleIntFloatArithmetic: 199ms 213ms 0.16us 1.272ms SimpleIntegerArithmetic: 200ms 209ms 0.16us 1.301ms SimpleListManipulation: 165ms 166ms 0.14us 1.379ms SimpleLongArithmetic: 132ms 137ms 0.21us 0.630ms SmallLists: 188ms 191ms 0.28us 0.844ms SmallTuples: 197ms 199ms 0.37us 0.951ms SpecialClassAttribute: 534ms 535ms 0.45us 1.121ms SpecialInstanceAttribute: 185ms 186ms 0.15us 1.125ms StringMappings: 471ms 471ms 1.87us 0.884ms StringPredicates: 190ms 191ms 0.27us 4.315ms StringSlicing: 285ms 290ms 0.52us 1.881ms TryExcept: 182ms 182ms 0.08us 1.663ms TryFinally: 134ms 136ms 0.85us 0.882ms TryRaiseExcept: 137ms 138ms 2.15us 0.885ms TupleSlicing: 202ms 204ms 0.78us 0.110ms WithFinally: 185ms 188ms 1.18us 0.881ms WithRaiseExcept: 274ms 275ms 3.44us 1.105ms ------------------------------------------------------------------------------- Totals: 10011ms 10120ms
Thanks Antoine! On Sun, Aug 24, 2008 at 5:58 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
So 3.0 is about 10% slower than 2.x. Given all the changes, that doesn't seem too bad. Though, see below. It looks like at least class attribute lookup is much, much slower. Can you investigate some of these and file bugs as appropriate?
I'm a little concerned about why the big change here. Though if I'm reading this right it's a speed up...or am I just being optimistic? The only things I remember that changed between 2.5 and 2.6 that might affect this (without looking at any code) were: 1) Armin's method caching, and 2) the slowdown to isinstance/issubclass which has a release blocker: http://bugs.python.org/issue2534 Can you dig into this and see what caused the slowdown?
Hopefully anything >10% is a real change and not just noise.
Maybe explained by Armin's patch.
Maybe explained by Armin's patch.
Maybe explained by Armin's patch.
Why? What changed?
Maybe explained by Armin's patch.
Whoa, that's a big slowdown. I wonder if it's consistent?
?
Much slower, but probably due to switch from int -> long. There could be potential for optimizing this case.
CompareIntegers: 277ms 277ms 0.15us 1.272ms
That's really slow!
CompareInternedStrings: 261ms 261ms 0.17us 3.201ms
Much slower, but probably str -> unicode conversion.
CompareLongs: 162ms 162ms 0.15us 0.736ms
But this is comparable to 2.x. I don't understand that?
This is much slower in 3.0, even taking into account str -> unicode?
Slower?
Over twice as slow?
Slower. str -> unicode?
~4x slower!
SpecialInstanceAttribute: 185ms 186ms 0.15us 1.125ms StringMappings: 471ms 471ms 1.87us 0.884ms
~3X slower.
Slower.
Hi,
So 3.0 is about 10% slower than 2.x. Given all the changes, that doesn't seem too bad.
Yes, I think it's rather good.
Yes, it is a speed up. It is thanks to Armin's method cache.
ComplexPythonFunctionCalls: 173ms 242ms -28.5% 176ms 243ms -27.6%
Maybe explained by Armin's patch.
Actually it is I and Raymond's patch speeding up function calls with named parameters.
DictCreation: 115ms 149ms -22.8% 116ms 150ms -22.8%
Why? What changed?
The opcode sequence for creation of dict literals has been optimized.
StringPredicates: 160ms 185ms -13.6% 160ms 186ms -13.9%
Maybe explained by Armin's patch.
I don't think so.
TryRaiseExcept: 183ms 122ms +49.6% 184ms 124ms +48.2%
Whoa, that's a big slowdown. I wonder if it's consistent?
Yes, I can definitely reproduce it.
UnicodePredicates: 157ms 175ms -10.2% 157ms 176ms -10.6%
?
Probably thanks to the speedup in whitespace detection.
Well honestly you don't often compare different types. I think the most common exception to this rule would be None vs. non-None.
I think CompareIntegers and CompareLongs aren't the same tests exactly, although they test the same operations. I've already proposed a patch to speedup comparisons in py3k: http://bugs.python.org/issue3106
ConcatStrings: 260ms 273ms 0.55us 1.222ms
This is much slower in 3.0, even taking into account str -> unicode?
The number of rounds is not the same (60000 for 2.6 with unicode, 100000 for 3.0 with str). It should probably be fixed.
IfThenElse: 212ms 212ms 0.16us 1.597ms
Slower?
It is based on integer comparisons though.
NormalClassAttribute: 339ms 340ms 0.28us 1.111ms
Over twice as slow?
Yes, should be investigated.
SimpleDictManipulation: 280ms 285ms 0.24us 1.059ms
Slower. str -> unicode?
No, there are just integers.
SpecialClassAttribute: 534ms 535ms 0.45us 1.121ms
~4x slower!
Should be investigated as well.
StringMappings: 471ms 471ms 1.87us 0.884ms
~3X slower.
It's normal. This test measures functions like upper(), etc., which are much expensive using the full unicode database than when doing a straight lookup in a 256-entry table.
Yes, the new exception semantics have a cost. Regards Antoine.
Antoine Pitrou schrieb:
Hi,
pystone ------- - 2.5: 43859.6 pystones/second - 2.6: 42016.8 pystones/second - 3.0: 38759.7 pystones/second
Well, pystone really doesn't test much of what causes the largest slowdowns in 3.0... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Mon, 25 Aug 2008 05:04:16 am Antoine Pitrou wrote:
Surely the most common None vs non-None comparison would be the "is" operator, which I hope remains fast. I don't know about other people, but I often compare floats with ints. Here's a contrived example: x = some_float() if x == -1: return -2 else: return (x**2-1)/(x+1) I suppose it's no hardship to start writing float literals instead of int literals, if needed. -- Steven
On 2008-08-24 21:04, Antoine Pitrou wrote:
That's a huge slow-down compared to 2.5. Are there any obvious reasons for this ? Has the exception handling mechanism changed that much between 2.5 and 2.6 ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 25 2008)
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
M.-A. Lemburg <mal <at> egenix.com> writes:
I've looked at it a bit and I think it's because of the issubclass()/isinstance() slowdown (which itself is due to ABCs). If I apply the patch in http://bugs.python.org/issue2534, the exception handling slowdown seems to disappear.
Antoine Pitrou <solipsis <at> pitrou.net> writes:
[...]
It turns out that these two slowdowns are due to classes always being new-style in py3k. Indeed, if I add "__metaclass__ = type" at the beginning of Tools/pybench/Lookups.py, 2.6 becomes as slow as 3.0. Regards Antoine.
participants (6)
-
Antoine Pitrou -
Georg Brandl -
M.-A. Lemburg -
Neal Norwitz -
skip＠pobox.com -
Steven D'Aprano