-----BEGIN PGP SIGNED MESSAGE-----
Fred Drake wrote:
> I have a need for 64-bit BTrees (at least for IOBTree and OIBTree),
> and I'm not the first. I've created a feature development branch for
> this, and checked in my initial implementation.
> I've modified the existing code to use PY_LONG_LONG instead of int for
> the key and/or value type; there's no longer a 32-bit version in the
> modified code. Any Python int or long that can fit in 64 bits is
> accepted; ValueError is raised for values that require 65 bits (or
> more). Keys and values that can be reported as Python ints are, and
> longs are only returned when the value cannot be converted to a Python
> This can have a substantial effect on memory consumption, since keys
> and/or values now take twice the space. There may be performance
> issues as well, but those have not been tested.
> There are new unit tests, but more are likely needed.
> If you're interested in getting the code from Subversion, it's available at:
> Ideally, this or some variation on this could be folded back into the
> main development for ZODB. If this is objectionable, making 64-bit
> btrees available would require introducing new versions of the btrees
> (possibly named LLBTree, LOBTree, and OLBTree).
I think coming up with new types is the only reasonable thing to do,
given the prevalence of persistent BTrees out in the wild. Changing the
runtime behavior (footprint, performance) of those objects is probably
not something which most users are going to want, at least not without
carefully considering the implications.
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -