On Thu, Jul 23, 2009 at 2:05 PM, Bart van der Schans<b.vandersch...@onehippo.com> wrote: > On Thu, Jul 23, 2009 at 1:50 PM, Guo Du<mrdu...@gmail.com> wrote: >> On Thu, Jul 23, 2009 at 12:37 PM, Bart van der >> Schans<b.vandersch...@onehippo.com> wrote: >>> Iirc there's a similar problem with multi value properties when you >>> add a lot of values. >>> >>> Is there any room left in the current implementation to improve the >>> performance of those two use cases? Or did somebody already look at it >>> thoroughly and squeezed out the last bit of performance gain? If not, >>> I would be happy to run some tests in a profiler and see what comes >>> up.. >>> >> >> By Alex: bundle pm stores nodes + its properties + its list of child >> nodes in a compact binary blob. >> >> This means read a node will load all child reference/properties to >> mem, I cannot see it could be improved significantly by bundle pm. >> It's possible with other pm store if the child/properties are stored >> separately. > It could be interesting to just add one table with (id,parent_id) and > remove the child node list from the bundle and separate the > hierarchical information from the content.
the current implementation is optimized for medium sized list of child node entries (~10-20k) and same-name sibling support. separating parent-child relations from node state would allow to support 'very' flat hierarchies, OTOH it would probably hurt performance when traversing hierarchies and when SNS are involved (apart from making the implementation considerably more complex). however, it might well be worth trying. go ahead, if you are up to it. cheers stefan > But I changing the storage > format is a huge change and I don't think it would justify the > performance gain. > > Bart > > > -- > Hippo B.V. - Amsterdam > Oosteinde 11, 1017 WT, Amsterdam, +31(0)20-5224466 > > Hippo USA Inc. - San Francisco > 101 H Street, Suite Q, Petaluma CA, 94952-3329, +1 (707) 773-4646 > ----------------------------------------------------------------- > http://www.onehippo.com - i...@onehippo.com > ----------------------------------------------------------------- >
