[Python-Dev] performance

[Antoine Pitrou]

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.