[Zope-CMF] [CMF 2.1] opaque items calls make performance issue

[toutpt]

Hanno Schlichting a écrit :
> On Mon, Aug 3, 2009 at 11:09 PM, toutpt<toutpt at gmail.com> wrote:
>   
>> I don't really understand why all these improvements are not merged
>> inside plone3.X and CMF and are marked up as 'experimental'.
>>     
>
> The opaque items issue at hand is not a simple and clear "bug fix". On
> the Plone level we have decided to no longer support this particular
> feature of CMF as it causes too much of a performance bottleneck for
> us. This is removing a feature which might be used by custom code or
> add-ons, even though there are no known add-ons, which actually depend
> on this feature. In a major release like the new Plone 4, we can make
> such a more radical change and remove a feature, but this has been too
> invasive to put into a Plone 3.x release.
>
> The improvements form the contentcreation package are similar and can
> potentially cause problems for code that relies on specific semantics
> during content creation in the portal_factory tool. The changes have
> been merged into the Plone 4 code as well now, but have been found to
> be too risky for Plone 3.x.
>
> The catalogqueryplan work is of a different kind and really requires a
> complete re-factoring of the catalog system as used in Plone to be
> done properly. Right now it is a set of monkey-patches for various
> internals of the catalog and the BTree classes. The work is also still
> ongoing to make the code more general. Since the catalog is one of the
> spots that thanks to its widespread use in Plone is also customized
> extensively, changes to it are particular risky to do.
>
> There is a whole number of other changes and techniques that are known
> to speed up Plone. One of the major problems is that these are often
> very easy to do given a particular single site, which can assume a lot
> of constraints about the way it is used. But the complexity of
> different usage patterns and the endless flexibility of configuration
> options make it very hard to improve performance in a general way.
>
> A typical issue of this kind is the question if a particular feature
> needs to be configurable per database configuration or just based on
> file system settings. In the latter case there can often be a number
> of things that can be cached at startup time avoiding the additional
> database lookups per view call. This is something Plone cannot do in
> general, but can bring substantial improvements for particular sites.
>
> Hanno
>   
Thank you for this very clear answer. I better understand your point of view and i will try to work in that way.