Python 2.x vs 3.x Speed
Question:
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.
Answers:
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.
This article (archive.org) 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.
Edit: Versions of Numpy which support Python 3 have since been released.
Edit2: This answer (and other answers to this question) are outdated.
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
EDIT: Just as Brian remarks, PEP 3146 was retired.
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.
Try refining the algorithms or changing the data structures used. That’s usually the best way to get an increase in performance.
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.
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.
This article (archive.org) 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.
Edit: Versions of Numpy which support Python 3 have since been released.
Edit2: This answer (and other answers to this question) are outdated.
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
EDIT: Just as Brian remarks, PEP 3146 was retired.
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.
Try refining the algorithms or changing the data structures used. That’s usually the best way to get an increase in performance.