An idea that I had at PyCon has finally come to fruition: introducing Psychotic, a pure Python optimizing compiler that achieves some pretty impressive results.
For a new project, Psychotic has a good deal of documentation. There’s also the introductory screencast, which is “lightning talk sized” (under 5 minutes).
There’s actually a fuller announcement over at the SitePen blog.
Cute? But this is the first project ever to break the Constant Time Barrier!
Giving false hope to the performance starved faithful is just plain wrong!
If you’re really performance starved, Python actually has a great collection of tools.
First, use a profiler to make sure you know what’s actually taking up the time.
Next, try to solve the problem in Python. You can do a lot of performance optimization completely within Python, especially in cases where you can change things around to leverage more of Python’s C code.
If you’re using Intel processors, consider using Psyco. In addition to “psyco.full()”, you can tell psyco to optimize only certain functions. That’s certainly a very easy thing to try.
Next, take a look at Cython. They have been doing a lot of work to build out the language to make the experience even more seamless when switching from Python.
And if all of that fails, you can still write C code. (or even D code: http://pyd.dsource.org/)
If all of this fails, and you have a command line program with only one set of inputs and outputs 
, you can use Psychotic.
So, truth be told… Python actually has a pretty darn good performance story to tell!
I know! I am developing uxpython.com so I know most of the tricks. I even use pyD, it’s just so much nicer than C 
The problem is that there does not seem to be any drive for making core python faster. The perception being that if performance is not being thought about then python will remain a niche scripting language. My thoughts being that the more code can be written in Python the better, and any performance enhancements really should be part of the batteries that are included.
But then again PyPy will save us all.
I keep thinking D looks nice, but I’ve never had a need.
IMHO, CPython’s performance is is “good enough”. Once you reach that threshold, it’s hard to get excited about squeezing out more. Yes, it would be great if it performed much better than it does, and I’m sure there are plenty of places for optimization. But, most programs written in Python do just fine… and those that need some performance help can just follow the steps I outlined above in specific areas of their code.
PyPy has a ways to go before it can truly replace CPython. It will certainly be exciting if it reaches that point. Oddly, in the meantime, Python will actually be getting a bit *slower* with the release of 3.0. But, again, CPython’s performance is “good enough” for most applications.
I personally think Python performs “good enough”, but some people dismis python because to them it’s not “good enough”.
(8x/800% slower than Java/.Net aka the competition from http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all but benchmarks always lie.)
It’s just the “Its good enough for me so it IS good enough” vibe that I object to since it leads to less people adopting python and is a problematic mindset long term.
> 8x/800% slower than Java
Beware averages!
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=python
Heh. Cute.