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