--------------------(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 > >
_______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
