solipsis at pitrou
Aug 24, 2008, 12:04 PM
Post #3 of 7
(501 views)
Permalink
|
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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
