> I was actually quite shocked when unladen swallow was somehow almost accepted for python 3.2 at some point, given how bad the performance results were
Memory is getting cheaper. I was looking forward the GIL removal (at first), but I'll be happy with any multi-threading improvement.
OTOH, when I really needed it, the multiprocessing module did the job nicely. And it also prevents some very hard to catch bugs.
Unladen has never intended to remove the GIL - their primary goal was to keep compatibility with C extensions without even recompiling IIRC (google seems to rely a lot on python extension around their infrastructure), and removing the GIL will break many, many extensions: the only known way to remove the GIL without cause a huge slow down is to remove reference counting, which C extensions rely on, and also most C extensions rely on the fact they don't need to be reentrant.
I run most of my Python program on fairly low end boxes, so consuming 9MB per process vs 90 would be a pretty big deal. If you have RAM to burn, share :).
In my use case, large data processing, I would prefer slower processing in exchange for lower memory requirements. The more ram it eats the sooner my processes have to hit disk.
Yes, I suppose you are right about the memory usage: http://www.python.org/dev/peps/pep-3146/#memory-usage. And of course Moore's law has been on target so far. However, next year I'll want to run more kinds of different processes, putting more projects on my servers and I'd rather conserve RAM as much as possible.
Memory is getting cheaper. I was looking forward the GIL removal (at first), but I'll be happy with any multi-threading improvement.
OTOH, when I really needed it, the multiprocessing module did the job nicely. And it also prevents some very hard to catch bugs.