Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Am 11.08.2009, 20:06 Uhr, schrieb yuppie : > I propose to split up CMFCatalogAware in CatalogAware, WorkflowAware and > OpaqueItemManager mixins. All the interfaces provided by these base > classes should be optional for CMF content. PortalFolderBase e.g. is not > catalog or workflow aware, so it should not use those base classes. This is an excellent idea! Finding out that the reason why my folderish objects were not being indexed because PortalFolder switches it off despire being CatalogAware was one of those "aha" experiences when moving towards a component architecture. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Hi! Hanno Schlichting wrote: > I don't know how such a feature removal or deprecation would be > handled on the CMF level. AFAICS IWorkflowAware and IOpaqueItemManager methods (as defined in CMF 2.2) were added to CMFCatalogAware because at that time events were not available and it was easier to have all manage_after* and manage_before* methods in one place. But IWorkflowAware and IOpaqueItemManager have nothing to do with ICatalogAware and I can no longer see a good reason to keep them all in one mixin. I propose to split up CMFCatalogAware in CatalogAware, WorkflowAware and OpaqueItemManager mixins. All the interfaces provided by these base classes should be optional for CMF content. PortalFolderBase e.g. is not catalog or workflow aware, so it should not use those base classes. In a next step we can replace the OpaqueItemManager base class by an adapter and provide an alternative adapter that just looks for talkback. That makes opaque item support configurable and we can disable it by default. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Charlie Clark a écrit : > Am 10.08.2009, 08:45 Uhr, schrieb toutpt : > > >> Thank you Charlie for this answer and this "Read The Fucking >> Interfaces" . >> > > Well, although it's a truism that if you read the code you'll find the > answer, it does also take a while to get used to reading the code of any > particular project. But as it stands the CMF code really is pretty > readable. > I was already read it but just not very well understood it. I m agree, CMF code is readable, i was just looking for other example than talkback or any blog post that speak about this feature. > >> I have done a simple egg that override the code: >> http://pypi.python.org/pypi/experimental.aggressiveopaquespeedup/ >> > > I'm not sure if I like the idea of a monkey patch directive. But with the > implementation I would have chosen a name like "remove/ignore opaque items" > > Charlie > I have discussed the name, and just having one answer from Hanno, now its too late but I m agree with you I just remove opaque items :). ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Am 10.08.2009, 08:45 Uhr, schrieb toutpt : > Thank you Charlie for this answer and this "Read The Fucking > Interfaces" . Well, although it's a truism that if you read the code you'll find the answer, it does also take a while to get used to reading the code of any particular project. But as it stands the CMF code really is pretty readable. > I have done a simple egg that override the code: > http://pypi.python.org/pypi/experimental.aggressiveopaquespeedup/ I'm not sure if I like the idea of a monkey patch directive. But with the implementation I would have chosen a name like "remove/ignore opaque items" Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Am 10.08.2009, 09:30 Uhr, schrieb Jens Vagelpohl : > No. See http://www.unicom.com/pw/reply-to-harmful.html for some > information why it's not a god idea. While I understand the technical problems, I don't think reply to all is actually much better and we do occasionally get posts to the list, the author and gmane with appropriately duplicaed answers. BeAM for BeOS/Haiku has a really nice "reply to list" option but as far as I know this is the only mailer to offer this. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 9, 2009, at 21:03 , Charlie Clark wrote: > From my previous answer to this which I forgot to send to the list > as well > - can we change the list settings so that answers go to it by default? No. See http://www.unicom.com/pw/reply-to-harmful.html for some information why it's not a god idea. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkp/zJoACgkQRAx5nvEhZLLplgCgpF3DLflX2kALxSSd2zRlmMaX 4gYAn2ZRkUgjUH2UQUFyhaf2JngB3aDk =dLSA -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Charlie Clark a écrit : > Am 09.08.2009, 04:48 Uhr, schrieb Martin Aspeli : > > self_base = aq_base(self) for name in self_base.__dict__.keys() obj = getattr(self, name) if ICallableOpaqueItem.providedBy(obj): items.append((obj.getId(), obj)) >> That's just *nuts*! >> > > From my previous answer to this which I forgot to send to the list as well > - can we change the list settings so that answers go to it by default? > > > CMF maintains pretty extensive backwards compatability. > > A similar question came up a couple of years ago and produced this > response from Tres: > > http://mail.zope.org/pipermail/zope-cmf/2007-March/025754.html > > ie. there is no reason why this should not be deprecated and replaced. > > Returning to the original questions: > > But z2ICallableOpaqueItem is a Zope2 interface and I m not used to this > kind of object. It seems they are generated on runtime, so for me it's > hard to debug. > > No, it's simply renamed on import in CMFCatalogAware > > * What are opaqueitems (any example ? I don't have find anything usefull > in tests of CMFCore) > > """ Interface for callable opaque items. > > o Opaque items are subelements that are contained using something that >is not an ObjectManager. > > o On add, copy, move and delete operations, a marked opaque items >'manage_afterAdd', 'manage_afterClone' and 'manage_beforeDelete' >hooks get called if available. Unavailable hooks do not throw >exceptions. > """ > > DiscussionItems are ICallableOpaqueItems > > * Is zope2 interface are still used and why ? > > For anything that uses OpaqueItems. From Tres' post it's pretty unlikely > that this is the case. The z2I "import as" has been removed in CMF trunk. > > * How could I replace those calls, or improved this code that always > return an empty tuple > > In you own deployments I suggest simply overriding the code to do just > that. > > Charlie > Thank you Charlie for this answer and this "Read The Fucking Interfaces" ;) . I have done a simple egg that override the code: http://pypi.python.org/pypi/experimental.aggressiveopaquespeedup/ - JeanMichel FRANCOIS aka toutpt ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Am 09.08.2009, 04:48 Uhr, schrieb Martin Aspeli : >>> self_base = aq_base(self) >>> for name in self_base.__dict__.keys() >>>obj = getattr(self, name) >>>if ICallableOpaqueItem.providedBy(obj): >>> items.append((obj.getId(), obj)) > That's just *nuts*! From my previous answer to this which I forgot to send to the list as well - can we change the list settings so that answers go to it by default? CMF maintains pretty extensive backwards compatability. A similar question came up a couple of years ago and produced this response from Tres: http://mail.zope.org/pipermail/zope-cmf/2007-March/025754.html ie. there is no reason why this should not be deprecated and replaced. Returning to the original questions: But z2ICallableOpaqueItem is a Zope2 interface and I m not used to this kind of object. It seems they are generated on runtime, so for me it's hard to debug. No, it's simply renamed on import in CMFCatalogAware * What are opaqueitems (any example ? I don't have find anything usefull in tests of CMFCore) """ Interface for callable opaque items. o Opaque items are subelements that are contained using something that is not an ObjectManager. o On add, copy, move and delete operations, a marked opaque items 'manage_afterAdd', 'manage_afterClone' and 'manage_beforeDelete' hooks get called if available. Unavailable hooks do not throw exceptions. """ DiscussionItems are ICallableOpaqueItems * Is zope2 interface are still used and why ? For anything that uses OpaqueItems. From Tres' post it's pretty unlikely that this is the case. The z2I "import as" has been removed in CMF trunk. * How could I replace those calls, or improved this code that always return an empty tuple In you own deployments I suggest simply overriding the code to do just that. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Wichert Akkerman wrote: > On 2009-8-8 11:53, Hanno Schlichting wrote: >> On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clark >> wrote: >>> Is the patch for Plone or CMF? >> It's for Plone, I guess. The "problem is solved" in Plone 4.0 itself >> (via monkey-patching CMF). >> >>> If it's for CMF then you should consider simply submitting a patch or >>> opening a branch. But before you write any package I would like to know a >>> little more about what exactly you want to do. >> The problem is the entire concept of opaque items. The only places I >> know they are still in use is the "talkback" objects as used by the >> discussion machinery in CMF. CMFUid also claims to implement the >> concept, but doesn't actually need any of the functionality, since it >> has its own event subscribers to deal with things. >> >> So the problem starts in >> CMFCore.CMFCatalogAware.dispatchToOpaqueItems, with the nice line: >> >> for opaque in ob.opaqueValues(): >> >> which in turn calls later on the opaqueItems method which contains this >> beauty: >> >> self_base = aq_base(self) >> for name in self_base.__dict__.keys() >>obj = getattr(self, name) >>if ICallableOpaqueItem.providedBy(obj): >> items.append((obj.getId(), obj)) That's just *nuts*! >> The whole method redispatches any IObjectEvent fired on an >> IOpaqueItemManager to any opaque item in it. In doing so, it needs to >> load every single entry in the objects __dict__ to see if it is an >> ICallableOpaqueItem. >> >> It happens that the CMFCatalogAware base class is such an >> IOpaqueItemManager, so any essentially any content object gets this >> treatment. > > Could it be that this considers dexterity content to be opaque items? I > have some code where events are recursively re-dispatched by CMF and I > suspect this is why. I can't see how that could happen. A Dexterity content item is a CMF content item, with the same base classes. And it certainly doesn't implement ICallableOpaqueItem. (Do note that Dexterity has an event handler to do some indexing, because in Plone 3/CMF 2.1 at least, it didn't happen automatically). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On 2009-8-8 11:53, Hanno Schlichting wrote: > On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clark wrote: >> Is the patch for Plone or CMF? > > It's for Plone, I guess. The "problem is solved" in Plone 4.0 itself > (via monkey-patching CMF). > >> If it's for CMF then you should consider simply submitting a patch or >> opening a branch. But before you write any package I would like to know a >> little more about what exactly you want to do. > > The problem is the entire concept of opaque items. The only places I > know they are still in use is the "talkback" objects as used by the > discussion machinery in CMF. CMFUid also claims to implement the > concept, but doesn't actually need any of the functionality, since it > has its own event subscribers to deal with things. > > So the problem starts in > CMFCore.CMFCatalogAware.dispatchToOpaqueItems, with the nice line: > > for opaque in ob.opaqueValues(): > > which in turn calls later on the opaqueItems method which contains this > beauty: > > self_base = aq_base(self) > for name in self_base.__dict__.keys() >obj = getattr(self, name) >if ICallableOpaqueItem.providedBy(obj): > items.append((obj.getId(), obj)) > > The whole method redispatches any IObjectEvent fired on an > IOpaqueItemManager to any opaque item in it. In doing so, it needs to > load every single entry in the objects __dict__ to see if it is an > ICallableOpaqueItem. > > It happens that the CMFCatalogAware base class is such an > IOpaqueItemManager, so any essentially any content object gets this > treatment. Could it be that this considers dexterity content to be opaque items? I have some code where events are recursively re-dispatched by CMF and I suspect this is why. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On Sat, Aug 8, 2009 at 12:14 AM, Charlie Clark wrote: > Is the patch for Plone or CMF? It's for Plone, I guess. The "problem is solved" in Plone 4.0 itself (via monkey-patching CMF). > If it's for CMF then you should consider simply submitting a patch or > opening a branch. But before you write any package I would like to know a > little more about what exactly you want to do. The problem is the entire concept of opaque items. The only places I know they are still in use is the "talkback" objects as used by the discussion machinery in CMF. CMFUid also claims to implement the concept, but doesn't actually need any of the functionality, since it has its own event subscribers to deal with things. So the problem starts in CMFCore.CMFCatalogAware.dispatchToOpaqueItems, with the nice line: for opaque in ob.opaqueValues(): which in turn calls later on the opaqueItems method which contains this beauty: self_base = aq_base(self) for name in self_base.__dict__.keys() obj = getattr(self, name) if ICallableOpaqueItem.providedBy(obj): items.append((obj.getId(), obj)) The whole method redispatches any IObjectEvent fired on an IOpaqueItemManager to any opaque item in it. In doing so, it needs to load every single entry in the objects __dict__ to see if it is an ICallableOpaqueItem. It happens that the CMFCatalogAware base class is such an IOpaqueItemManager, so any essentially any content object gets this treatment. Now imagine you edit the title of a folderish type containing 1000+ items. Thanks to the above you will also load all items it contains from the database. Any add/delete/edit operation on a large folderish type suddenly becomes increasingly slow. On the Plone level we decided to no longer support the opaque items concept except for the talkback item. That simplifies the whole overhead into a simple attribute lookup for that one item and avoids the overhead of checking every contained item. I don't know how such a feature removal or deprecation would be handled on the CMF level. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Am 07.08.2009, 22:17 Uhr, schrieb toutpt : > experimental.opaquespeedup is good but not enough for me. The load tests > results are not enough, I want to be more 'aggressive' and > experimental. For me this package is backward compatible and do a > catalog query instead of parsing all attributes. I want to do nothing > except support 'talkback'. I want also to release this package on pypi, > and I want your opionons: > * makina.opaquespeedup (makina is where I m working) > * experimental.aggressiveopaquespeedup > * any other idea ? > My vote goes to experimental.aggressiveopaquespeedup Is the patch for Plone or CMF? If it's for CMF then you should consider simply submitting a patch or opening a branch. But before you write any package I would like to know a little more about what exactly you want to do. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On Fri, Aug 7, 2009 at 9:17 PM, toutpt wrote: > experimental.opaquespeedup is good but not enough for me. The load tests > results are not enough, I want to be more 'aggressive' and > experimental. For me this package is backward compatible and do a > catalog query instead of parsing all attributes. I want to do nothing > except support 'talkback'. I want also to release this package on pypi, > and I want your opionons: > > * makina.opaquespeedup (makina is where I m working) > * experimental.aggressiveopaquespeedup > * any other idea ? > > My vote goes to experimental.aggressiveopaquespeedup Either way is fine, just pick the one you like :) Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
David Glick a écrit : > On Aug 3, 2009, at 1:46 PM, toutpt wrote: > >> Hi, >> >> I m currently profiling the code of Plone to find performance issue and >> fix them (i m sure there are a lot). >> >> There are things I don't understand very well, so sorry if I m wrong. >> >> The code of CMFCatalogAware.opaqueItems parse every attributes of >> plonesite and evaluate this for each attribute: >> >> ICallableOpaqueItem.providedBy(obj) or >> z2ICallableOpaqueItem.isImplementedBy(obj) >> >> isImplementedBy calls takes 30% of the time spent. >> >> But z2ICallableOpaqueItem is a Zope2 interface and I m not used to this >> kind of object. It seems they are generated on runtime, so for me it's >> hard to debug. >> >> My questions are: >> >> * What are opaqueitems (any example ? I don't have find anything usefull >> in tests of CMFCore) >> * Is zope2 interface are still used and why ? >> * How could I replace those calls, or improved this code that always >> return an empty tuple >> >> PS: sorry for cross posting if there are because i have some issues >> with my other email address. >> >> - JeanMichel FRANCOIS aka toutpt > > > This has already been fixed in Plone 4 (by monkey-patching CMF to only > pay attention to the 'talkback' opaque item which is used for > discussions). In Plone 3 you can avoid this performance issue by > installing the experimental.opaquespeedup package (thanks to Jarn) -- > http://pypi.python.org/pypi/experimental.opaquespeedup > > > David Glick > Web Developer > ONE/Northwest > experimental.opaquespeedup is good but not enough for me. The load tests results are not enough, I want to be more 'aggressive' and experimental. For me this package is backward compatible and do a catalog query instead of parsing all attributes. I want to do nothing except support 'talkback'. I want also to release this package on pypi, and I want your opionons: * makina.opaquespeedup (makina is where I m working) * experimental.aggressiveopaquespeedup * any other idea ? My vote goes to experimental.aggressiveopaquespeedup ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Hanno Schlichting a écrit : > On Mon, Aug 3, 2009 at 11:09 PM, toutpt 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. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On Mon, Aug 3, 2009 at 11:09 PM, toutpt 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 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Hanno Schlichting a écrit : > On Mon, Aug 3, 2009 at 10:46 PM, toutpt wrote: > >> I m currently profiling the code of Plone to find performance issue and >> fix them (i m sure there are a lot). >> > > Did you try to install all the experimental.* (opaquespeedup, > contentcreation, catalogqueryplan) packages that have been done over > the last year? They help to address some of the known performance > problems. > > For the particular issue at hand you can either use the opaquespeedup > package which has a more conservative approach to fixing this issue or > backport the approach taken in Plone 4 as per > https://svn.plone.org/svn/plone/Plone/branches/4.0/Products/CMFPlone/patches/speed.py > > Hanno > I don't really understand why all these improvements are not merged inside plone3.X and CMF and are marked up as 'experimental'. That has been discuss on Plone dev ML. This has to be merged It's lots of work and make a lots of benefits to Plone. CMF and Plone are still slow. I will install those packages. JeanMichel FRANCOIS aka toutpt. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On Mon, Aug 3, 2009 at 10:46 PM, toutpt wrote: > I m currently profiling the code of Plone to find performance issue and > fix them (i m sure there are a lot). Did you try to install all the experimental.* (opaquespeedup, contentcreation, catalogqueryplan) packages that have been done over the last year? They help to address some of the known performance problems. For the particular issue at hand you can either use the opaquespeedup package which has a more conservative approach to fixing this issue or backport the approach taken in Plone 4 as per https://svn.plone.org/svn/plone/Plone/branches/4.0/Products/CMFPlone/patches/speed.py Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
On Aug 3, 2009, at 1:46 PM, toutpt wrote: > Hi, > > I m currently profiling the code of Plone to find performance issue > and > fix them (i m sure there are a lot). > > There are things I don't understand very well, so sorry if I m wrong. > > The code of CMFCatalogAware.opaqueItems parse every attributes of > plonesite and evaluate this for each attribute: > > ICallableOpaqueItem.providedBy(obj) or > z2ICallableOpaqueItem.isImplementedBy(obj) > > isImplementedBy calls takes 30% of the time spent. > > But z2ICallableOpaqueItem is a Zope2 interface and I m not used to > this > kind of object. It seems they are generated on runtime, so for me it's > hard to debug. > > My questions are: > > * What are opaqueitems (any example ? I don't have find anything > usefull > in tests of CMFCore) > * Is zope2 interface are still used and why ? > * How could I replace those calls, or improved this code that always > return an empty tuple > > PS: sorry for cross posting if there are because i have some issues > with my other email address. > > - JeanMichel FRANCOIS aka toutpt This has already been fixed in Plone 4 (by monkey-patching CMF to only pay attention to the 'talkback' opaque item which is used for discussions). In Plone 3 you can avoid this performance issue by installing the experimental.opaquespeedup package (thanks to Jarn) -- http://pypi.python.org/pypi/experimental.opaquespeedup David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidgl...@onenw.org work: (206) 286-1235 x32 mobile: (206) 679-3833 Subscribe to ONEList, our email newsletter! Practical advice for effective online engagement http://www.onenw.org/full_signup ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Hi, I m currently profiling the code of Plone to find performance issue and fix them (i m sure there are a lot). There are things I don't understand very well, so sorry if I m wrong. The code of CMFCatalogAware.opaqueItems parse every attributes of plonesite and evaluate this for each attribute: ICallableOpaqueItem.providedBy(obj) or z2ICallableOpaqueItem.isImplementedBy(obj) isImplementedBy calls takes 30% of the time spent. But z2ICallableOpaqueItem is a Zope2 interface and I m not used to this kind of object. It seems they are generated on runtime, so for me it's hard to debug. My questions are: * What are opaqueitems (any example ? I don't have find anything usefull in tests of CMFCore) * Is zope2 interface are still used and why ? * How could I replace those calls, or improved this code that always return an empty tuple PS: sorry for cross posting if there are because i have some issues with my other email address. - JeanMichel FRANCOIS aka toutpt ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
