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

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

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

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

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:
> > >

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]