This post originated from an RSS feed registered with Python Buzz by Ian Bicking. Original Post: Speed is a Process, not an Attribute Feed Title: Ian Bicking Feed URL: http://www.ianbicking.org/feeds/atom.xml Feed Description: Thoughts on Python and Programming. Latest Python Buzz Posts Latest Python Buzz Posts by Ian Bicking Latest Posts From Ian Bicking

or: Python vs. C Extensions

Any reader of the Python list/group (comp.lang.python) will have become used to the "Is Python Right For Me?" queries, typically with a question about performance. The typical answer is that if Python's performance is problematic, you can code key portions in C -- at an extreme, Python can be a scripting language for your C (or C++, or now even Objective C) application.

I don't think this is a very good answer, because it's not the answer that most Python programmers come to. Extension programming is a sort of release valve -- it means there's always a way out if you need it. Python can never be worse than C, because you can always rewrite more and more of your code in C until your application performs sufficiently. But it really is a release valve, and like a release valve it's only there in case of emergency.

I think the real answer to these people should be: Python is fast enough just as it is. Your application may not be fast enough when you first write it in Python, but you can almost always make Python -- just Python -- perform sufficiently. This isn't true for every domain, but it's true for the most common programs.

C is good for one kind of performance -- running code really fast. But this is only one kind of performance, and now that CPUs are so fast it's not the most important kind of performance. Programs have bottlenecks, and nothing but the bottleneck matters. CPUs are not the bottleneck!

Two applications that reminded me of this: Evolution and Mail.app. At least for my usage, Mail.app runs much faster than Evolution (and Sylpheed and any other mail reader I've tried). This isn't because of language or runtime differences. Mail.app runs faster because it is smarter. I have big IMAP mailboxes, and Mail.app caches messages intelligently, checks those caches intelligently, and does its best to queue IMAP queries for quick response to what I'm most interested in.

Mail.app isn't written in Python, but it shows what good optimization is -- it's not just executing code fast, it's executing only as much code as necessary, and being responsive.

So, I think when someone asks if Python performance is an issue, tell them no, and don't apologize for Python by pointing to the release valve of C extensions. If you can write a full-featured Python program twice as fast as C (probably more like 10x, but for argument...), that leaves the Python programmer a lot of time to think about how to make the program more responsive. Some of that time spent in optimization could be used to mitigate Python's relatively slow computation, but more likely it will be spent avoiding expensive operations with disks and networks. In the end, I would expect the pure Python program to be faster than the C program (given an equal amount of programmer time).