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. > > - 2.5: 770.54 ms per iteration > > - 2.6: 572.84 ms per iteration > > - 3.0: 566.69 ms per iteration > > 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? 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. > > CompareFloatsIntegers: 274ms 274ms 0.30us 0.630ms > > Much slower, but probably due to switch from int -> long. There could > be potential for optimizing this case. Well honestly you don't often compare different types. I think the most common exception to this rule would be None vs. non-None. > > 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? 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. > > WithFinally: 185ms 188ms 1.18us 0.881ms > > WithRaiseExcept: 274ms 275ms 3.44us 1.105ms > > Slower. Yes, the new exception semantics have a cost. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com