Hey, Tres Seaver wrote: [snip] > In general, if you need full-on backward compatibility with the existing > behavior of Zope2 / Zope3 / Grok, switching to a paste-driven WSGI > pipeline doesn't gain you much speed (but it is not a loss, either). > If, for a given application, you can relax the BBB requirement, then > some performance wins are available via WSGI which can't be made in the > monolithic publisher (dropping out features by removing the middleware > layer).
As for Grok I hope we can break some backwards compatibility and get some larger performance speedups. We definitely need to aggressively keep moving forward in this area. Not even primarily for speed gains but also for comprehensibility; I find Chris's "what's it doing" report far more worrying than differences in speed at this point: http://plope.com/whatsitdoing2 This is why zope.pipeline is such an important effort to me. Not that it will immediately make things better, but it would hopefully open up a path to move the Zope Framework forward in this area. > Real speed wins only come from more radical simplifications: for > instance, repoze.bfg drops the adapter-based traversal semantics in > favor of using only __getitem__. The fact that the BFG "hello world" > app is ~20 times faster[1] than the Grok "hello world" is due to such > simplifications. In a hello world the overhead of the publisher dominates in a way that in normal applications it probably doesn't, so what are "real speed wins", as usual, will depend. Improvements in template language implementations might gain us more. That said, recent profiling of Grok with chameleon make that a small component too, so perhaps it *is* the publisher. Oh the joys of profiling! :) Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )