hi florent On 4/19/06, Florent Guillaume <[EMAIL PROTECTED]> wrote: > Stefan Guggisberg wrote: > > btw: you should in general try to avoid flat hierarchies in jackrabbit > > as they come at a certain performance cost. > > Hi Stefan, > > Could you expand a bit on that? Aren't there any BTree-like structures used > to store children on unordered nodes? Does this depend on the backend > storage? Are any linear searches attempted in some places?
the NodeState object, jackrabbit's internal representation of a jcr Node, maintains the collection of child node entries (name, subscript, uuid). hash maps are used for accessing accessing an entry by name or uuid. have a look at the NodeState and NodeState #ChildNodeEntries classes in the o.a.j.core.state package. this should answer all your questions. 'fat' nodes take longer to load, copy and store. they obviously also use up more memory and therefore may affect gc performance. manipulating a large collection of same-name sibling entries (remove/insert) may take more time than performing the same operation on a smaller collection. cheers stefan > > Thanks, > Florent > > -- > Florent Guillaume, Nuxeo (Paris, France) Director of R&D > +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] >
