[Python-Dev] Re: Python 2.1 slower than 2.0

M.-A. Lemburg mal at lemburg.com
Mon Jan 29 07:24:15 EST 2001


Here the results of my micro benckmark pybench 0.7:

PYBENCH 0.7

Benchmark: /home/lemburg/tmp/pybench-2.1a1.pyb (rounds=10, warp=20)

Tests:                              per run    per oper.  diff *
------------------------------------------------------------------------
          BuiltinFunctionCalls:    1102.30 ms    8.65 us   +7.56%
           BuiltinMethodLookup:     966.75 ms    1.84 us   +4.56%
                 ConcatStrings:    1198.55 ms    7.99 us  +11.63%
                 ConcatUnicode:    1835.60 ms   12.24 us  +19.29%
               CreateInstances:    1556.40 ms   37.06 us   +2.49%
       CreateStringsWithConcat:    1396.70 ms    6.98 us   +5.44%
       CreateUnicodeWithConcat:    1895.80 ms    9.48 us  +31.61%
                  DictCreation:    1760.50 ms   11.74 us   +2.43%
                      ForLoops:    1426.90 ms  142.69 us   -7.51%
                    IfThenElse:    1155.25 ms    1.71 us   -6.24%
                   ListSlicing:     555.40 ms  158.69 us   -4.14%
                NestedForLoops:     784.55 ms    2.24 us   -6.33%
          NormalClassAttribute:    1052.80 ms    1.75 us  -10.42%
       NormalInstanceAttribute:    1053.80 ms    1.76 us   +0.89%
           PythonFunctionCalls:    1127.50 ms    6.83 us  +12.56%
             PythonMethodCalls:     909.10 ms   12.12 us   +9.70%
                     Recursion:     942.40 ms   75.39 us  +23.74%
                  SecondImport:     924.20 ms   36.97 us   +3.98%
           SecondPackageImport:     951.10 ms   38.04 us   +6.16%
         SecondSubmoduleImport:    1211.30 ms   48.45 us   +7.69%
       SimpleComplexArithmetic:    1635.30 ms    7.43 us   +5.58%
        SimpleDictManipulation:     963.35 ms    3.21 us   -0.57%
         SimpleFloatArithmetic:     877.00 ms    1.59 us   -2.92%
      SimpleIntFloatArithmetic:     851.10 ms    1.29 us   -5.89%
       SimpleIntegerArithmetic:     850.05 ms    1.29 us   -6.41%
        SimpleListManipulation:    1168.50 ms    4.33 us   +8.14%
          SimpleLongArithmetic:    1231.15 ms    7.46 us   +1.52%
                    SmallLists:    2153.35 ms    8.44 us  +10.77%
                   SmallTuples:    1314.65 ms    5.48 us   +3.80%
         SpecialClassAttribute:    1050.80 ms    1.75 us   +1.48%
      SpecialInstanceAttribute:    1248.75 ms    2.08 us   -2.32%
                StringMappings:    1702.60 ms   13.51 us  +19.69%
              StringPredicates:    1024.25 ms    3.66 us  -25.49%
                 StringSlicing:    1093.35 ms    6.25 us   +4.35%
                     TryExcept:    1584.85 ms    1.06 us  -10.90%
                TryRaiseExcept:    1239.50 ms   82.63 us   +4.64%
                  TupleSlicing:     983.00 ms    9.36 us   +3.36%
               UnicodeMappings:    1631.65 ms   90.65 us  +42.76%
             UnicodePredicates:    1762.10 ms    7.83 us  +15.99%
             UnicodeProperties:    1410.80 ms    7.05 us  +19.57%
                UnicodeSlicing:    1366.20 ms    7.81 us  +19.23%
------------------------------------------------------------------------
            Average round time:   58001.00 ms              +3.30%

*) measured against: /home/lemburg/tmp/pybench-2.0.pyb (rounds=10, warp=20)

The benchmark is available here in case someone wants to verify
the results on different platforms:

	http://www.lemburg.com/python/pybench-0.7.zip

The above tests were done on a Linux 2.2 system, AMD K6 233MHz. 
The figures shown compare CVS Python (2.1a1) against stock
Python 2.0. 

As you can see, Python function calls have suffered
a lot for some reason. Unicode mappings and other Unicode database
related methods show the effect of the compression of the Unicode
database -- a clear space/speed tradeoff. 

I can't really explain why Unicode concatenation has had a 
slowdown -- perhaps the new coercion logic has something to
do with this ?!

On the nice side: attribute lookups are faster; probably due to
the string key optimizations in the dictionary implementation.
Loops and exceptions are also a tad faster.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/




More information about the Python-list mailing list