[Grok-dev] Performance of OrderedContainer

[Gary Poster]

On Jun 17, 2008, at 1:58 PM, Gary Poster wrote:

>
> On Jun 17, 2008, at 6:05 AM, Sebastian Ware wrote:
>
>> I was looking at the trunk of grok because I need to use  
>> OrderedContainer. But, if I add say 1 million objects to an  
>> OrderedContainer, won't it become very slow due to the  
>> implementation with PersistentList? Say that I want to show the  
>> last 100 of the objects, I would have to return all 1 million keys.
>
> Big ordered mappings are one of the use cases for zc.blist.  The  
> following is a description, including the mechanism.
>
> http://svn.zope.org/zc.blist/trunk/src/zc/blist/README.txt?view=auto
>
> The set of edge cases is very large, and so the tests are primarily  
> of the "run random operations for hours to try and find a problem".   
> I've run them for four or five hours now without any bugs.  I intend  
> to release 1.0 soon, and some internal ZC projects will be using it  
> soon.
>
> It can be a drop in replacement for PersistentList in an ordered  
> mapping implementation.  The only potential incompatibility I can  
> think of is that getting a slice returns an iterator rather than a  
> list.

Heh, no reply to this, but, FWIW, I thought about this a bit more  
later in the day.  You probably don't want to drop a blist in without  
thinking about how to make the container code (the API for changing  
the order) leverage the blist possibilities.  If the API is simply  
something to the effect of "change order", like the standard zope.app  
ordered container uses, the blist will be a loss.  If instead the API  
invites making small changes to the order (moving an item or range of  
items from one part of the list to another, for instance; or switching  
items in the order) the blist can be a nice win.

I'm not familiar with the grok OrderedContainer (unless it is a  
wrapper of the zope.app one).

Gary