[Tres Seaver]
> ...
> I would guess that if you could do a census of all the OIDs in all the
> Datas.fs in the world, a significant majority of them would be instances
> of classes declared in IOBTree / IIBTree (certainly the bulk of
> *transaction* records are going to be tied up with them).
Provided it still works, people can use ZODB's analyze.py to figure that out.
But supposing "I" flavors of BTrees are the only objects that exist,
what follows from that? It's not clear. I can guarantee that
multiunion() will run slower, because its workhorse radix sort will
need 8 (instead of 4) passes. Beyond that, it requires someone to try
it. I'm reminded that when the MEMS Exchange wrote Durus (a kind of
"ZODB lite" ;-):
http://www.mems-exchange.org/software/durus/
)
they left their entire BTree implementation coded in Python -- it was
"fast enough" that way. The difference between ZODB's BTree C code
pushing 4 or 8 bytes around at a time may well be insignificant
overall.
If done carefully, pickle sizes probably won't change: cPickle has a
large number of ways to pickle integers, and picks the smallest one
needed to hold an integer's actual value. Provided the internal
getstate() functions are careful to avoid Python longs when possible,
bigger pickles won't happen unless more than 32 bits are actually
needed to hold an integer.
There's also that ZODB's current "I" trees are badly broken on 64-bit
boxes (except for Win64) in at least this way:
http://collector.zope.org/Zope/1592
That problem would go away by magic.
looks-like-a-case-of-measure-twice-cut-once-ly y'rs - tim
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
