[Zope-dev] Zope.pipeline proposal

[Martijn Faassen]

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