> I have some performance experiences from this that'd I'd love to share if
> I ever had the time, which I might soon, but for now I have no hard
> numbers so I won't elaborate on the cache issue being the cause, but
> increasing the cache size has a definite improvement in performance for
> broader queries.
The ZODB cache size only affects how many objects are retained in memory
*across* transaction boundaries. Within a single transaction, it has no
direct effect at all; if increasing the ZODB cache size helps "broader
queries", then they must benefit from retaining more objects in memory from
> I presume your proposal would help out a lot in this regard by making
> the system smarter about how to handle lots of little objects.
Since the thrust of Dieter's sketch is to make the cache boot out very large
objects first, that may be a wishful presumption <wink>. It may even be
counter-productive for your application, if, e.g., your top-level indexing
structure becomes a very large object. Then it might get booted out of the
cache after every transaction just because "it's big", despite that every
transaction uses it. I doubt that's likely, just not impossible.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org