Re: [Evolution-hackers] ... and how camel should be

[Dave Richards <drichard largo com>]

I added this comment to the bugzilla report.  I'm not a developer, but I do have to *deploy* Evolution to hundreds of people.


--------------------(snip)-------------------------------------------------------------------------------------------------------------
I have been watching this thread on evolution-hackers.  Please remember when considering design of these things, that some of us are running multi-user systems with hundreds of users on at a time.  There might be cases where memory is better than disks in such cases.  I have hundreds of users and can easily get all of this into 16GB.  What will be the result of all of those people now using the disk?


On Mon, 2006-02-13 at 22:54 +0100, Philip Van Hoof wrote:
> Added comment to 
>
> http://bugzilla.gnome.org/show_bug.cgi?id=331017
>
> My reasoning why also evolution would benefit from the proposed
> improvements. And why evolution today probably uses a lot memory while
> this is in many cases totally unnecessary.
>
> --- 
>
> You can replace the word "camel" with "evolution" in these sentences.
>
> Camel design flaws:
>
> Camel keeps a copy of all message-id's in memory
> (camel_folder_get_uids). It would be better if in stead of a GPtrArray,
> it would return an iterator. It could then keeps those uids on disk.
>
> Imagine a folder 

> with 10.000 e-mails (it's not insanely lot, isn't it?).
> There's very few mobile devices that can handle such large "GPtrArray"
> allocations. And given the fact that only at most 20 headers are visible
> in the header summary view, it's totally unnecessary to load all 10.000
> message-id's into memory. Camel requires you to do this.
>
> Camel reads too much information per such header into memory. For a
> summary view only the by-the-user selected columns are necessary in
> memory. For example only the message-id, from, mime-type, subject and
> date.
>
> Camel doesn't make it possible to retrieve the message headers in a
> sorted way. Therefore the user interface developer needs to use a slow
> gtktreesortable. Imagine that for sorting, the treeview needs to read
> all those 10.000 message headers. That's dog slow on a device that needs
> swap space to store the 10.000 headers in it's virtual memory space. It
> would be much faster if I could get an iterator that simply gives the
> ->next in a sorted fashion. Then sorting would simply be assigning a new
> iterator to the model and letting the treeviews redraw hocus-pocus make
> it look like sorting actually happened. Only the 20 or so visible rows
> would be read. The 9.990 others wouldn't.
>
>
> On Mon, 2006-02-13 at 22:38 +0100, Philip Van Hoof wrote:
> > On Mon, 2006-02-13 at 15:10 -0500, Jeffrey Stedfast wrote:
> > > This would take several years to implement - likely to require complete
> > > rewrites of at least some of the providers.
> > > 
> > > I don't really see this happening anytime soon.
> > 
> > What about the disk summary branch?
> > 
> > Will this branch have likewise functionality?
> > 
> > Can I be of any assistance? Redoing something like Camel would take me
> > even more years. So I figured ... if I'm going to need it, my best bet
> > would be to adjust camel in such a way that it does become like this.
> > 
> > What would that mean for the Evolution team? In the end, Evolution's
> > memory usage during typical application usage would be reduced. I think
> > that at this moment a vast amount of Evolutions memory goes into these
> > design issues.
> > 
> > It "would" greatly improve the memory usage of the header summary view
> > yet keep it sortable.
> > 
> > The start of the disk summary branch was the right thing to do.
> > 
> > Let's pick it up.
> > 
> > 
> > Difficult is fun.
> > 
> > 
> > > On Mon, 2006-02-13 at 18:29 +0100, Philip Van Hoof wrote:
> > > > http://bugzilla.gnome.org/show_bug.cgi?id=331017
> > 
> >