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

[Philip Van Hoof <spam pvanhoof be>]

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
> 
> 
-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be