Since you believe this using C to reduce function call overhead is cheating, here's Pyramid 1.0a9 profiling output with the "zope.interface" C optimizations disabled (same methodology and code used to test the C-optimized variant):
That's 27 lines of profiler output, which, if you're keeping score, is still fewer lines than any other framework tested. We're not really hiding anything here.
The comparisons to other frameworks are largely a gimmick to drive traffic and comments, granted. In the real world, these numbers shouldn't make the difference about whether you choose one framework or another.
However, there are actual speedups to be had by other Python web frameworks if they'd consider using some of the techniques outlined in the blog post. In the real world, actual benchmarks seem to have Pyramid bottlenecked by the WSGI server (see for example http://blog.curiasolutions.com/2010/11/the-great-web-technol...), so the optimizations we're doing are working, AFAICT.
http://plope.com/static/noncoptimized.txt
That's 27 lines of profiler output, which, if you're keeping score, is still fewer lines than any other framework tested. We're not really hiding anything here.
The comparisons to other frameworks are largely a gimmick to drive traffic and comments, granted. In the real world, these numbers shouldn't make the difference about whether you choose one framework or another.
However, there are actual speedups to be had by other Python web frameworks if they'd consider using some of the techniques outlined in the blog post. In the real world, actual benchmarks seem to have Pyramid bottlenecked by the WSGI server (see for example http://blog.curiasolutions.com/2010/11/the-great-web-technol...), so the optimizations we're doing are working, AFAICT.