Re: [Evolution] IMAP speed

On Wed, 2002-11-20 at 12:45, Scott Otterson wrote:
Jeff, those are great numbers but I suspect the test isn't measuring the
thing I'm talking about.  What I'm talking about is amount of time
evolution spends rechecking message headers and updating vfolders.  For
example, I just did this:

ah, so now it's vFolders... 

- started evolution
- waited for the INBOX to show up (lots of messages about vfolders
                                   scanning for new headers)
- open an email
- delete that email
- click on a different email header
- again, I see a bunch of messages about scanning for new headers, etc.

The delay for the 2nd check is about as long as when I first started
evolution.  I haven't yet figured out when evolution decides to go
through all this checking and rechecking but it seems to be quite a lot
more often than 1.08.  This really makes evolution harder to use on a
slow modem connection.

Can you think of a way to test this aspect?  Do you think that the
checking and rechecking is because of evolutions's interaction with UW
IMAP v.s. other kinds of IMAP?  If so, the problem is solvable because
the mozilla IMAP doesn't spend this much time checking and rechecking.

what I don't understand is why you are comparing Evolution's
vFolder-over-IMAP speed to Mozilla's plain IMAP speed. Of course
Mozilla's plain IMAP is gonna be faster.

vFolders are going to be much slower than normal physical folders,
especially on IMAP.

As NotZed said, can you open a bugzilla bug about "vFolders are slow
over IMAP on dialup" and then attach your vFolder rules, IMAP server
type, and rough message-counts/sizes? Maybe even a timed results for how
fast stuff loaded in 1.0.8 compared to 1.2.0? As far as I know, this
should all be faster... but it'd be good to get times to compare.

I'm not sure why NotZed thought you were getting a deadlock. Are you?

In the meantime, I suggest you stop using vFolders and instead setup
server-side filtering. This will make your experience *much* faster I



On Tue, 2002-11-19 at 17:56, Jeffrey Stedfast wrote:
Since no one wants to listen to me, I've spent the past few hours
building Evolution 1.0.8 and deps on my Celeron 400 box at home here (a
multitude of hops away from our IMAP Courier server) and did the

- killev
- rm -rf ~/evolution
- evolution
- create imap account - left on all default options (except I had to
turn on SSL). These options are as follows:

[ ] Automatically check for new mail ...
[X] Check for new messages in all folders
[X] Show only subscribed folders
[ ] Override server-supplied namespace
[ ] Apply filters to new messages in INBOX

- select local Inbox folder (so that the next time we start up it will
not load any IMAP folders, shouldn't be an issue but ah well)
- close evolution
- killev; evolution
- select fejj imap ximian com/INBOX/bugzilla
- immediately start stopwatch
- wait for message-list to load
- stop stopwatch immediately

The results I got were as follows:

Evolution 1.2.0: time = 4:25:48
Evolution 1.0.8: time = 10:09:75

Seems to me that Evolution 1.2.0 is quite a bit faster than Eolution
1.0.8 to me... more than 2 times faster in fact.

Since you come from, I suspect you probably use
uw.imapd, which may explain your problem - uw.imapd is known to be
extremely inefficient. I would suggest you install a faster imap server
such as Courier imapd or (the even faster?) Cyrus imapd.


On Tue, 2002-11-19 at 20:23, Not Zed wrote:
On Wed, 2002-11-20 at 10:29, Scott Otterson wrote:
OK, sounds good.  But, as I understood you this morning, you were
convinced that the PPP problem did not exist.

I've dont plenty of testing with disconnecting, and it works fine.  It
takes a while and eventually times out.  If i reconnect the network, it
just keeps going again.

Just to make sure we're talking about the same thing, what's the number
for the open bug on PPP disconnects causing an IMAP hang?


IMAP and POP are separate.

There might be some threading contention where a thread is 'busy'
waiting for a timeout, but it isn't hanging.


On Tue, 2002-11-19 at 14:22, Jeffrey Stedfast wrote:
they are 1) unrelated and 2) already reported.


On Tue, 2002-11-19 at 17:16, Scott Otterson wrote:
Why not?  It's clear that there's a bug in evolution and that it's not a
fundamental flaw with Linux.

Now, if the stop button bug and the PPP-disconnect-hang bug are
manifestations of the same problem, then I agree that it doesn't make
sense to file a new one -- that is, if there is a non-closed stop button
bug and if it is known that these are really the same problem.  

Are both these things true?


On Tue, 2002-11-19 at 13:33, Jeffrey Stedfast wrote:
please do not submit new bug reports, thanks.


On Tue, 2002-11-19 at 16:15, Scott Otterson wrote:
Yes, Ettore, you're right about the stop button not working -- and
there's at least one bug on it but it was closed as fixed even though it

Is the stop button problem also causing the PPP-disconnect-induced
hangs?  Or should I file a separate bug?  Anyway, you're right that this
isn't a problem with Linux: Mozilla on Linux handles PPP disconnects
just fine.


On Tue, 2002-11-19 at 11:38, Ettore Perazzoli wrote:
On Tue, 2002-11-19 at 13:12, Jeffrey Stedfast wrote:
On reading your response, my first thought was, "Boy, linux must be
lame," because on Windows, nothing hangs when you lose your PPP -- not
outlook, not mozilla, not anything as far as I know.

wonderful about those win32 apis for finding out when the connection
goes down. Not available on linux.

Having the Stop button working properly in all cases in the mailer would
be a good starting point though.  ;-)

It is true that we have a bug there, and it can be fixed, and there is
no reason to blame Linux for it.

Ettore Perazzoli <ettore ximian com>

evolution maillist  -  evolution ximian com
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  -

evolution maillist  -  evolution ximian com
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  -

evolution maillist  -  evolution ximian com

evolution maillist  -  evolution ximian com

Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  -

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