I use PyPy almost exclusively. I like the availability of their precompiled binaries, and other peoples' benchmarking criticisms aside it's orders of magnitude faster than standard Python in all of my actual applications.
psycopg2cffi fixed the psycopg2 issue some time ago.
I've run into compatibility issues with packages that reference math-centric libs (matplotlib?) but aside from that I've been quite happy with it.
Coincidentally I tried PyPy today for my shell, which is around 14K lines of completely unoptimized Python code [1]. I have never used PyPy before, despite being a long-time Python programmer.
I didn't expect PyPy to speed it up, just based on my impressions of the kind of workloads PyPy excels at.
In my first test case (parsing a 976 line shell script), PyPy took 2.0 seconds and Cpython took 1.0. And that 2x slower number held up for other a couple other tests.
I will probably try running the benchmark in a loop to see if PyPy's JIT warms up (does it do that?). But I wasn't really expecting to use PyPy -- I just wanted to see how it does, because there aren't many ways to speed up my code without rewriting a good portion of it.
My impression is that JITs don't work well in general for certain workloads, not just PyPy. IIRC LuaJIT is actually slower than Lua for string-processing workloads. It makes a lot of sense in say machine learning applications which are all floating point calculations. But string processing is probably dominated by allocations and locality, and the JIT doesn't do very much there, whether it's LuaJIT or PyPy.
I probably overstated... I don't think JITs including LuaJIT do much for string manipulation, but that would mean it's on par with Lua.
Off the top of my head I think of Lua/Python as 10-100x slower than C, but LuaJIT might get you within 2x for some numerical workloads. But it will not get you within 2x for string workloads -- it's still in the 10x or worse category.
Someone reported a slower benchmark here but the maintainer argued that is invalid. But he says all the time is within C functions, which is what I was getting at.
I think the bottom line is that the semantics of Lua strings are completely different than how you manage strings in C, so there's a limit to how much you can optimize the program, even if you have a lot of time to (which the JIT does not.)
So if I have an existing Django application in production, assuming no package compatibility issues, how long might it take to get it running with PyPy?
I have a production Django application (the https://www.pastery.net pastebin). Just for fun, I'm going to change the container's image from python:3 to pypy:3 and document what happens here.
EDIT:
* Failed building psycopg2. Apparently I need to use psycopg2cffi instead. Retrying...
* manage.py now can't import Django. Hmm.
* Yeah, I have no idea why it can't import Django. I took most of the settings out of settings.py, thinking it somehow caused an ImportError, but it still fails. I think I have to give up at this point, as I have no more guesses.
* Turns out manage.py was trying to launch `/usr/bin/env python` and it needed `/usr/bin/env pypy3`. Seems odd to include a `python` binary on the image and not just alias it to `pypy3`, but it is what it is. Continuing...
Welp, everything seems to be running just fine. Here's the diff of all the changes I had to make:
Basically, install psycopg2cffi instead of psycopg2, use pypy3 for the interpreter instead of python, and add two lines to settings.py. All in all, pretty damn short!
Thanks! I'll be doing this soon too then. Most of my apps don't rely on too many obscure packages and / or really large scientific computing packages, so I doubt I'll run into many problems either.
psycopg2cffi fixed the psycopg2 issue some time ago.
I've run into compatibility issues with packages that reference math-centric libs (matplotlib?) but aside from that I've been quite happy with it.