On 19/03/2008, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> Peter Bengtsson wrote at 2008-3-18 17:38 +0000:
> >I wanted to see how much faster brain.getObject() would be if the
> >returned object was located in a BTreeFolder versus a normal folder so
> >I wrote a benchmark that created about 10,000 light simple objects in
> >two distinctly different containers and each with a ZCatalog that has
> >a PathIndex.
> >I would expect the BTreeFolder parenting calls of brain.getObject() to
> >be much faster but I found that there was NO DIFFERENCE. wtf?!
> If you access many (most) objects, these accesses may be even
> more expensive with a "BTreeFolder" than with a standard folder.
> This is not that difficult to explain:
> When you access a normal folder, with the folder all child
> references are loaded. When you later access the folder
> again (and it has not yet been flushed from the ZODB cache),
> no loading is necessary.
> When you access a "BTreeFolder", no child references are loaded.
> Thus, elementary access to a "BTreeFolder" is much more
> When you access a child in a "BTreeFolder", then all child
> references are loaded that are in the same bucket as the
> access child. In addition, all nodes on the path
> from the "BTreeFolder" to this bucket are loaded.
> When you access many children, you have a good chance,
> that you have accessed at least on child in each bucket.
> In this case, you have loaded all child references (as
> in the standard folder case). In addition, you have
> loaded the complete access structure.
> To summarize: an isolated access to a child of a large "BTreeFolder"
> is usually much more efficient than an isolated access to a standard
> folder with the same children. However, the advantage of the
> "BTreeFolder" decreases when lots of children are accessed.
...because they're cached in the normal folder.
So, to rewrite my benchmark I'd have to flush the cache between each fetch?
I don't mind because the app itself has little traffic but individual
pages are slow.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -