views:

373

answers:

5

I'm a PhD student and use Python to write the code I use for my research. My workflow often consists of making a small change to the code, running the program, seeing whether the results improved, and repeating the process. Because of this, I find myself spending more time waiting for my program to run than I do actually working on it (a common experience, I know). I'm currently using the most recent version of Python 2 on my system, so my question is whether switching to Python 3 is going to give me any speed boost or not. At this point, I don't really have a compelling reason to move to Python 3, so if the execution speeds are similar, I'll probably just stick with 2.x. I know I'm going to have to modify my code a bit to get it working in Python 3, so it's not trivial to just test it on both versions to see which runs faster. I'd need to be reasonably confident I will get a speed improvement before I spend the time updating my code to Python 3.

+2  A: 

I can't answer the root of your question, but if you read anything regarding the sluggish performance of the io module please disregard it. The were definitely performance issues in Python 3.0, but they were largely resolved in Python 3.1.

Eric Palakovich Carr
I did see something about that when I googling around. Good to know.
Colin
Eric, have you got a link to anything authoritative that you could add? I've still got the idea (after reading the "What's New" docs among other things) that although 3.1 improved things a lot, it was by no means a case of restoring the speed to where 2.5 was at.
Peter Hansen
I attended a meetup with Steve Holden and Eric Smith (chairman of the Python Software Foundation and contributor to the 3.1 changes respectively) and both said that things were much improved over 3.0 for the io module. I don't remember if they commented on how performance compared to the 2.x branch as it was a few months ago now.So I can't say 3.1's io module is better than 2.5, but I can say 3.1 is better than 3.0.
Eric Palakovich Carr
Thanks Eric, that's helpful. I notice that the `io` module appears to be getting ported to 2.7, so I guess one could easily compare the old and new I/O performance. See http://docs.python.org/dev/whatsnew/2.7.html
Peter Hansen
Stumbled over a link to this on Planet Python: http://www.dabeaz.com/blog/2010/01/reexamining-python-3-text-io.html It describes how text I/O in 3.1 is still quite a bit slower than in 2.6. Slower for good reason (Unicode) but still slower. Worth a read.
Peter Hansen
Very interesting. Thanks for the link. +1
Eric Palakovich Carr
+10  A: 

This article said that there were a few points where Python 3.0 was actually slower than Python 2.6, though I think many of these issues were resolved. That being said, Numpy hasn't been brought over to Python 3.0 yet and that's where a lot of the high performance (written in c) number functionality stuff is hiding. Hopefully it will be ready late 2009 or early 2010.

You should not consider performance to be a justification to switch to Python 3; I don't think you'll see a consistent speed improvement.

Brian
That's good enough for me. I'm new to Python so I wasn't sure what the goals were for Python 3, but speed doesn't seem to be one of them.
Colin
> Hopefully it will be ready late 2009 or early 2010. (it's already 2010 so I doubt they will hit a 2009 release date :)
Corey Goldberg
@Colin: True. To go a step further, speed was largely ignored. The philosophy is probably something like, "make it work, *then* make it faster." The goals for Python 3: http://wiki.python.org/moin/Python3.0
Brian
+4  A: 

Right now, speed on Python 3 is more or less the same as Python 2... If you're looking for speed, it's not on Python 3 vs Python 2 but in other tools like Psyco, Cython, etc...

But, very recently, there have arisen plans to merge Unladen Swallow, the Google project to implement a JIT over Python with Python 3. Of course, it won't be very soon, but, in some time, maybe the speed will increase noticeably on Python 3 over Python 2. They claim to have already increased speed on a 10% (on Python 2). Their objective is increasing the speed to 5x.

For more information, see PEP 3146

Khelben
+2  A: 

I have phylogenetics analysis that takes a long time to run, and uses about a half-dozen python scripts as well as other bioinformatics software (muscle, clustal, blast, even R!). I use temp files to save intermediate results and a master script with the subprocess module to glue all the pieces together. It's easy to change the master to run only the modified parts that I want to test. But, if the changes are being made to early steps, and you only know how good it is at the end of the whole process, then this strategy wouldn't help much.

telliott99
+1  A: 

Try refining the algorithms or changing the data structures used. That's usually the best way to get an increase in performance.

omouse