Re: [Zope-dev] Re: BTreeFolder
Shane Hathaway wrote: > > "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. > > > So, all things considered, you get faster access, fewer conflicts, and > less RAM usage. Can't beat that. :-) Indeed... sounds _very_ cool :-) Any idea when we're likely to see a release? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: BTreeFolder
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: BTreeFolder
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. --- Hannu ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: BTreeFolder
"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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: BTreeFolder
At 09:19 AM 4/27/01 -0700, Michael Bernstein wrote: >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? Yes. Whenever I get around to updating ZPatterns for Zope 2.3.x, I plan to switch to the new BTrees. However, if you can't wait for that, you can always hand-edit the import statements in Rack.py to do the right thing. That will only work for new rack objects, or at any rate for racks that haven't yet created their BTree. 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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: BTreeFolder
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: BTreeFolder
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. :-) Cool. From my point of view it'd be great if the default folders in the CMF could be these new 'super folders' I can think of some situations where I might end up with _large_ number of objects in a CMF folder :-S thanks for the reply, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: BTreeFolder
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. :-) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
