views:

36

answers:

1

Hi,

I have a bunch of apps written in Python 2.4. I'd like to port them onto more recent version of the interpreter. Let's say I have no need of syntax features, but I am very concerned about performance. So which of the upper python versions is the fastest (the most optimized) - 2.4 or 2.5 or 2.6 or 2.7 ?

Performance comparison articles (URL) are much appreciated.

Thanks

+4  A: 

In general, each successive version along the 2.* line becomes a bit faster than the previous one -- because optimization and fine-tuning is a high priority for many contributors.

I don't know of any articles on performance configuration: my advice is to identify the "hot spots" of your specific application by profiling (but surely you're already doing that, if you are "very concerned about performance") and turn them into microbenchmarks to run on timeit across all four versions.

For example, suppose that ''.joining middling-length lists of shortish strings is known to be a hotspot in your applications. Then, we could measure:

$ python2.4 -mtimeit -s'x=[str(i) for i in range(99)]' '"".join(x)'
100000 loops, best of 3: 2.87 usec per loop
$ python2.5 -mtimeit -s'x=[str(i) for i in range(99)]' '"".join(x)'
100000 loops, best of 3: 3.02 usec per loop
$ python2.6 -mtimeit -s'x=[str(i) for i in range(99)]' '"".join(x)'
100000 loops, best of 3: 2.7 usec per loop
$ python2.7 -mtimeit -s'x=[str(i) for i in range(99)]' '"".join(x)'
100000 loops, best of 3: 2.12 usec per loop

python2.5 in this case does not follow the other releases' general trend (repeating the measurement confirms it's about 5% slower than python2.4 on this microbenchmark) and 2.7 is surprisingly faster than expected (a whopping 26%+ faster than 2.4), but that's for a specific build and platform (as well of course as a specific microbenchmark), which is why it's important for you to perform such measurements on benchmarks and platforms/builds of your specific interest (if you're willing to just accept the general consideration that later builds tend to be faster, then you're not really "very" concerned about performance;-).

Alex Martelli
Testing on each one involves updating / rebuilding C++ extensions written using Boost Python, which is very time consuming...
Alex
@Alex, if you can't isolate micro-benchmarks that matter to you without them involving the extensions, it must mean that the extensions are taking basically all the time (otherwise you could isolate and measure the performance-relevant parts where the extensions are **not** the bottlenecks), and therefore that worrying about the performance of Python proper is a totally misplaced idea.
Alex Martelli