Hi Chris > Betreff: Re: [Zope-dev] Zope.pipeline proposal > > Roger Ineichen wrote: > > Hi Tres > > > >>>> 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. > > While I think that would be a good thing, I do want to > mention that it's not really the point of the "whatsitdoing" > benchmark. > > Repoze stuff typically tries to simplify each component in > the set of components used to service a goal, sometimes at > the expense of at least some backwards compatibility or > excessive configurability. On the other hand, Zope3 and Grok > tend to keep backwards compatibility and configurability > sometimes at the expense of verbosity and extra runtime > expense. They are just somewhat different goals. Repoze > stuff therefore has the major advantage of not needing to > carry around 6-10 years of backwards compatibility baggage; > it owes any 20-20 hindsight in these cases of course directly to Zope. > > In the meantime, we are proud of the work we've been doing to > simplify Zopelike publishing, and the "whatsitdoing" > benchmark was really just a mechanism to toot that particular > horn. I'm not sure how to toot that horn without comparing > it to Zope, so while I see that it has ruffled some feathers, > I'll stand by the benchmark as a useful comparison. I'm > pretty sure the stuff would fare pretty well on some other > less objective benchmark (like "developer productvity" as you > seem to be advocating). > > FTR, the "publishing implementation" you speak of above in > the case of repoze is is really a different framework > altogether: http://static.repoze.org/bfgdocs/ .
I see what you mean. I really have to deep into the repoze packages. It defently looks very promising! btw, Don't get me wrong. I really appreciate your great work. It's one of this pieces we need for make better progress. Regards Roger Ineichen > - C > _______________________________________________ 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 )
