[Python-Dev] performance (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Sun Aug 24 21:04:16 CEST 2008

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.

More information about the Python-Dev mailing list