[Zope-dev] Re: 64-bit BTrees

[Philipp von Weitershausen]

Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> in memory. Dieter estimates 20% to 35% slowdown for the C algorithms
>> (whatever that means), Tim seems to think it won't have such a big
>> effect. I guess we'll only know after some benchmarks.
> 
> Can we please not make any definite decisions until this issue has been
> resolved, some of us do actually care about performance ;-)

Nobody made any decisions. I just expressed my opinion. In the above
quoted paragraph I merely said that the only real implication seems to
be a possible performance loss (pickle size and pickle compatibility
seems not to be a problem). Since we don't know how much of a
performance loss that would be, I suggested Fred would do some
benchmarks so that the decision we would come to eventually would be an
informed one and not be based on wild guesses.

> Yes, ideally, I'd like to see just IIBTree's but only if there are not
> perfomance implications. I think BTrees sit low enough in the stack that
> it's perfectly justifiable to have both an I BTree and an L BTree.
> 
> If having two isn't acceptable, then why do we have an I and O BTree's,
> not to mention the special ones used for in-memory ZODB indexes? Surely
> we should just have one BTree class?

I see your point. Note that this "one" BTree class you're talking about
already exists: OOBTree :). The I*BTree flavours are just there for
optimization because things like the catalog deal with integer IDs a
lot. Now they have to deal with larger integers than before; I'd rather
not create yet another special BTree flavour.

Philipp