[Zope3-dev] zwiki: performance of findChildren()

[Shane Hathaway]

Stephan Richter wrote:
> On Monday 21 April 2003 11:00, Marcus J. Ertl wrote:
> 
>>I'm just doing some work on developing a threaded forum for zope3.
>>Zwiki was a great place to steal some code ...errr.. a great place of
>>inspiration!
>>
>>The only thing I found was: If I use your system of parenting, e.g.
>>findChildren, I get in performance trouble, if I generated up to 25.000
>>messages (=wikipages), and tried to build a part of the toc!
>>
>>Any ideas to speed this up?
> 
> 
> Caching or rewriting the parent support.
> 
> Rewriting means: Instead of storing the parent in the wiki page itself, you 
> could store it as a child in the parent. This way findChildren() will be much 
> less expensive. 
> 
> However, for a threaded forum I would do it differently and build a true 
> object hierarchy (which is not that good for Wikis - which is an exception). 
> Basically, make every Message a Folder. Then you simply place messages into 
> messages and so on, and you have naturally a tree and all the folder 
> functionality.
> 
> Since Wikis are general graphs, this method cannot be used for them.

I wouldn't introduce a true hierarchy into Wikis, either.

Instead, to satisfy both needs (simplicity and scaleability), Wikis 
should depend on an external component that keeps track of Wiki 
structure.  The simple version of the component should store Wiki 
structure information as annotations on Wiki pages.  The scaleable 
version should either build an index, cache, or rely on an object hub in 
some way.  I might call this the "Wiki page relationship" service.  This 
service should be notified of every change to a Wiki page.  This service 
should  answer any useful query about the relationship between Wiki pages.

FWIW, ZWiki for Zope 2 seemed to progress in a direction similar to 
this.  Instead of figuring out their own parentage, ZWiki pages delegate 
relationship computations to a temporary class instance.  The difference 
I'm suggesting is that the relationship manager should be a 
configurable, persistent component instead of a temporary instance of a 
fixed class.

Shane