On Wed, 2007-10-31 at 10:47 -0400, David Binger wrote: > On Oct 31, 2007, at 7:35 AM, Roché Compaan wrote: > > > Thanks for the explanation. > > The actual insertion is very fast. Your benchmark is dominated by > the time to serialize the changes due to an insertion. > > You should usually have just 2 instances to serialize per insertion of > a new instance: the instance itself and the b-node that points to the > instance. An insertion may also cause changes in 2 or several b-nodes, > but those cases are less likely. > > Serializing your simple instances is probably fast, but serializing > the b-nodes appears to be taking much more time, and probably accounts > for the large number of calls to persistent_id. B-Nodes with higher > branching factors will have more parts to serialize and they will be > slower. If you can cut the b-node branching factor in half, I bet your > benchmark will run almost twice as fast.
I increased the 'DEFAULT_MAX_BUCKET_SIZE' from 30 to 30000 and DEFAULT_MAX_BTREE_SIZE from 250 to 2500 and it didn't make any noticeable difference. Despite this change there are still a huge amount of unexplained calls to the 'persistent_id' method of the ObjectWriter in serialize.py. Running fsdump on the Data.fs confirmed that there are only 2 instances serialized per insertion, one OOBucket and an instance of the persistent class used for testing. So thus far the only tweak that made a significant difference was increasing the DB cache size from 400 to 100000. -- 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