Shane Hathaway wrote:

Chris Withers wrote:

...

will you be releasing a new version of BTreeFolder that makes use of the new funky BTrees at any stage?

We've done some work on it; in fact Jim came up with a bold new idea that makes them inherently faster. Now to find the time. :-)

Does this have any implications for the BTree implementation used in ZPatterns Racks? Michael Bernstein.

"Phillip J. Eby" wrote:

Now, what *I*'d like to know is what the "bold new idea" is, since it sounds like it's something even newer than the forward-chained-buckets-plus-conflict-resolution stuff that's already been released.

It's simple, really. BTreeFolders play havoc with acquisition because every time you pass through them, looking for some name, they perform a lookup in a BTree. This wouldn't be an issue if it weren't for the fact that many sites use implicit acquisition heavily--I once measured 4500 lookups in a simple request to the management interface. But if the items stored in the BTree follow some simple pattern, we don't have to perform a BTree lookup for things that don't follow the pattern. The most useful pattern would be a string prefix followed by an integer, which would allow us to use an IOBTree (meaning integer keys and object values) for storage. Jim claims an IOBTree is faster. :-) So when scripts go looking all the way up the tree for the name REQUEST a hundred times (a common thing to do), the BTreeFolder can ignore it. The other cool idea he came up with is allowing the folder to decide what the ID of a new object is going to be so the folder can try to avoid conflicts with other ZEO clients. Many Zope applications use time stamps for IDs, but doing that can lead to frequent conflicts. Random IDs avoid conflicts. However, purely random IDs would cause all the buckets to be loaded in memory all the time, so Jim's third idea was to have each client increment sequentially from a random ID and move to a new random ID if conflicts ever occur. So, all things considered, you get faster access, fewer conflicts, and less RAM usage. Can't beat that. :-) Shane

Hannu Krosing wrote:

Shane Hathaway wrote:

...

However, purely random IDs would cause all the buckets to be loaded in memory all the time, so Jim's third idea was to have each client increment sequentially from a random ID and move to a new random ID if conflicts ever occur.

Can't one just assign some unique id to each ZEO client and somehow use _that_ for making up ids ?

It would have the added benefit of knowing which client made up which id.

I suppose, but I don't see much value in that for most ZEO setups, since a browser is not bound to a specific client. Shane