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 _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com