Re: [Evolution] Evo memory use

[Not Zed <notzed ximian com>]

On Fri, 2003-02-14 at 20:54, David Woodhouse wrote:
> On Fri, 2003-02-14 at 02:30, Not Zed wrote:
> > evolution stores a subset of the headers of  every message of every
> > opened folder in memory.
>
> Note that when Evolution is separated from the IMAP server by a slow WAN
> link, the mere fact that it thinks it's necessary to fetch the headers
> for _every_ message even in the mailbox(es) you currently have open is a
> bug far more severe than the memory usage.

Hmm, i'm not sure what you mean here.  It only fetches the headers that
are new.  Or if the server is changing the UIDVALIDITY field, in which
case we must refetch all headers (as per rfc2060).

> You know how many messages there are in the mailbox so you can make your
> scrollbar scale correctly. You can fill in the 'unknown' entries in the 
> list with some suitable placeholder text and replace that text with the
> _actual_ message information if and when the relevant list entries are
> actually displayed on-screen. You can even fetch the message headers for
> the non-displayed messages in the background to populate your cache, as
> long as there's no user-driver IMAP activity which should take
> precedence -- but there's absolutely no excuse for making the user wait
> while you download all the headers, before you even start to display the
> list.

Actually there's a couple of reasons :)

 - updating etable has been extremely slow, and very buggy, we tried
some incremental update for local mail, and that either caused etable to
crash a lot, or if we rebuilt the tree every now and then, it was just
way too slow (it really bogs down your system).
 - partially its the abstraction layers used, although there is actually
no technical reason why the current abstraction can't be used in a
different way at a lower level and implement this behaviour.
 - there's still the problem of how to display mail arriving with
sorting on, which can make it next to unusable to use the display while
new things get added.

The main reason is the first, the code hasn't been fast enough, although
etable in 1.4 is looking significantly faster so it may become
possible.  We might even get enough bugs out of it to incrementally
build the tree rather than having to discard and rebuild from scratch
every time, which would make it easy.

The second issue is more work to fix, although, not impossible.  We just
need to throw out 'folder updated' events during long processing, at the
low level imap engine.

Lastly, I hate the IMAP code probably more than you do, i have to help
maintain it :)

 Z

PS someone else wrote the imap code originally ...