It depends on your use case.

In my experience the reason why you wrote something in python (implement features faster) remain valid reasons later on when you want to add functionality.

By using pypy, cpython, rewriting small parts in C/C++ and/or using the libraries which are written in C (such as numpy) you can normally make the hotspots in your code fast enough, while keeping the advantages of python.

In my experience it is worthwhile to first try and improve the performance in Python. It's easier to play around with different ideas in Python, and things like numpy quite often enable you to get "fast enough". Only if that is not enough should you consider writing a C extension.

I've never had to do this, but the common advice I hear is that the right algorithm in a high level language can be faster then the wrong algorithm in a low level language. So even if you do end up going the route of writing it in something lower level, it is likely worth optimizing your code at the higher level first where it is less expensive to try different things.

Same question to you: if you have some code that really has to be fast, is it viable to keep it in C++, or should you ultimately end up rewriting it for GPU?

No doubt. I'm loving hendrix (and, thus, twisted). It has given me renewed enthusiasm for python as a networking language.

Come check out #hendrix on freenode.

Also disadvantages: increased programmer time for implementing new features. Risks: you might optimize the wrong part (i.e. you invest into rewrite, but it will not solve performance problems).

That's why you must quantify advantages and disadvantages, including risks minimization and only then you'll see, whether given course of action is viable.

It depends on what you're doing. I think your strategy can often be high risk since you are making a change that affects every part of your program at once -changing the runtime on a mature Python project is not a trivial choice! Changing the relevant code to tidy up data structures, or moving a few function calls to Cython or C, however, will only touch the obvious places and so it has less impact on the program.

Also, profiling pypy is less straightforward than profiling CPython code since the hotspot changes the runtime characteristics of the program. This means you need to run tests many times over to make sure the code warms up. This makes further optimizations slightly more difficult. It's not a problem for people with experience optimizing Python code, but for people who actually hope to learn something from OP's blog post, it might be a sticking point.

In my experience in using Python for stats, script type work (as opposed to writing servers and daemons), pypy just isn't that useful. All the Python code is doing is gluing numpy and Cython code together and pypy isn't likely to be able to warm up in time to beat it - and it won't beat it since it's spending most of its time in C.

Obviously, if pypy is an ideal choice for you, use it. But I don't think your experience should really be put forward as a general approach.

Jython is not running on an interpreter.

It IS an interpret itself, and it runs on a virtual machine that takes care of JIT compilation.

Python in CPython is executed after being compiled to the lower-level Python bytecode. Is this not sufficient to consider CPython to involve a virtual machine?

Almost all interpreters compile an ast to an "assembly code" that gets executed. CPython even executes that assembly code without seeing the source at all just like Java.