I just tried to evolution to look at email in a large folder (c 100,000
unread messages). I'm using evo 2.22 on Debian Lenny; the cyrus IMAP
server is on the same machine as evo.
I was using a threaded view with threads collapsed, and a filter on the
message sender (the filter was to exclude all messages from one sender).
If I scroll the message, or move some messages from the message list
into another folder, evo displays "generating message list" and becomes
unresponsive for over a minute, using most of my CPU. This is unusable.
In some quick experiments it seems the filter is the key contributor to
I think it also went into these unresponsive states at other times,
including when I was doing nothing.
I also experience significant delays when I drag messages into folders
with many messages. Doing so seems to trigger a scan of the target
folder, even though messages from it are not displayed.
Is there anything I can do about this (apart from don't do that advice
like don't use filters, don't use large mailboxes, don't use
I gather evo doesn't have real threads, which may account for some of
these issues (e.g., rescanning messages blocks unrelated user
activities, including even composing mail).
But the behavior is sub-optimal on two levels. First, the IMAP server
could provide much of the desired functionality. I know not all mail
stores, or even all IMAP servers, provide the necessary functionality,
but it would be nice to use it when it's there. Second, evo is clearly
working much too hard. If I delete some messages, it shouldn't need to
regenerate the whole list to figure out what is left. It only needs to
display enough info to fill up the message view pane. Since it seems to
be generating the entire message list, I don't know why it has to do
that every time I scroll.
I guess some of this discussion belongs on the developer list, but my
first question is as a user: is there anything I can do to improve the