[ZODB-Dev] PersistentMapping good for large numbers of objects?

[Tim Peters]

[Shane Hathaway]
> ...
> Yep.  So what I have in mind is passing around an "int *deltaLength"
> in BTree mutating functions.  The mutators would modify *deltaLength
> as they work, then at the end of the operation (involving many
> nodes), that deltaLength (which exists only on the stack) would be
> given to some other object.  It's similar to the way BTrees used to
> work: they stored a length in the root BTree node.

I don't know how many years it took to get all the bugs out of the BTree
mutating functions, because I've only been staring at them for two <wink>.
Seriously, adding any more complexity to that code instinctively repels me
now.  If it's going to be a high-use feature with major advantages over all
other approaches, I can overcome that.

> This assumes that for every BTree-mutating operation, there is a
> function that gets called externally but never internally.  The
> external function is where we'd call length.change().  It's common
> for Python extensions to separate external and internal functions,
> but I haven't looked at whether the BTrees code uses that pattern.
> If it doesn't, this idea is no good. ;-)

I wouldn't worry about that part.  I don't know either whether it's
universally true now, but if it isn't then I'm sure it's so close to being
univerally true that the difference between here and there would cost more
to measure than to eliminate <wink>.