On Sun, 2008-02-03 at 22:05 +0100, Dieter Maurer wrote: > The number of "persitent_id" calls suggests that a written > persistent object has a mean value of 65 subobjects -- which > fits well will OOBuckets. > > However, when the profile is for commits with 100 insertions each, > then the number of written persistent objects is far too small. > In fact, we would expect about 200 persistent object writes per transaction: > the 100 new persistent objects assigned plus about as many buckets > changed by these insertions.
I don't follow? There are 20000 insertions and there are 1338046 calls to persistent_id. Doesn't this suggest that there are 66 objects persisted per insertion? This seems way to high? > > .... > >The keys that I lookup are completely random so it is probably the case > >that the lookup causes disk lookups all the time. If this is the case, > >is 230ms not still to slow? > > Unreasonably slow in fact. > > A tree with size 10**7 does likely not have a depth larger than 4 > (internal nodes should typically have at least 125 entries, leaves should have > at least 15 -- a tree of depth 4 thus can have about 125**3*15 = 29.x * > 10**6). > Therefore, one would expect at most 4 disk accesses. > > On my (6 year old) computer, a disk access can take up to 30 ms. The lookup times I reported were wrong. There was a bug in the code that reported the lookup time - the correct average lookup time for a BTree with 10 million objects was an impressive 12 ms. For Postgres this was 14 ms. -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev