> >> 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.
> > I absolutly agree!
> > As far as I can see, the repoze sample doesn't open a ZODB
> which makes
> > it not really comparable.
> I think you've made Chris' point for him: nothing about the
> application being tested *requires* that there be a ZODB
> connection open; Grok's design forces opening one
> unconditionally, which is a layer of complexity which *can't
> be turned off.* The "conceptual" overhead of each of the
> frameworks is at least as important as the performance overhead.
Yes, that's true. But I like to see the real performance win
within a *real* application. My applications normaly do not
only show a hello world page ;-)
I also like to see how much the repoze method calls will
grow if the authentication, transaction, ZODB etc is involved.
I'm pretty sure that it will much less then 20 times like in
the given test. I'll also be happy if we will gain a 2 time
perfomance factor in a real comparable test app.
I've developed a prototyping package in my own personal repos
which tries to setup a site within some objects which I use with
the old zope server and a paste WSGI server setup.
This let us run performance tests against the ZODB. Probably
I should add that to the zope repos and we could start adding all
our different publishing implementations. This whould let us
compare the same things in a real world use case.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -