Re: [Evolution] IMAP speed

[Jeffrey Stedfast <fejj ximian com>]

On Tue, 2002-11-19 at 22:19, Marcus Brubaker wrote:
> On Tue, 2002-11-19 at 20: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
> > following:
> >
> > - 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 u.washington.edu, 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.
> >
> > Jeff
>
> And for the people for whom installing a different IMAP server isn't an
> option?  A lot of people don't have control over what software their
> IMAP server is running.
>
> Yes, IMAP in 1.2 may be considerably faster for Courier IMAPd.

it's faster for presumably every server *except* uw.imapd.

>   But a
> lot of people don't use Courier or Cyrus and don't have the option or
> the desire to do so.

then complain to the authors of your sucky imap server. you sure don't
seem to be shy about blaming projects that aren't to blame.

>   (If it works, why replace it even if you do have
> the option?  I think we all have better things to do with our time than
> that.)  If it used to work well and now it doesn't work so well, it *IS*
> a regression.

*shrug* stick to evolution 1.0.8 then. you have the choice to either
install a better imap server or keep running 1.0.8. no one is forcing
you to run 1.2.0.

> If people update to a new version of a 3d game which claims to give you
> better framerates on OpenGL capable cards and when someone actually runs
> it they find out that this is only true if you're using a Matrox card
> and in fact, if you're using NVidia or any other brand card, it has
> WORSE performance, their going to be understandably upset.

you're comparing apples and oranges. a closer analogy would be:

vendor claims new version of 3d game runs faster on 3d cards with
support for OpenGL and the user happens to have a 2d video card or a 3d
video card that sucks out the rear.

>   And when the
> people who respond to it first tell them it's their fault and quit
> bothering them instead of just saying "Ok, well right now we don't have
> time to look at it, file a bug (or add yourself to the cc of a
> pre-existing bug) and we'll get to it when we can,"  people tend to get
> a bit annoyed and frustrated.

file bugs to your imap server vendor. it's not our job to work around
suckiness in other people's code. it's their problem, not ours. people
seem to forget that, and "it's not fair".

and before you try and remind me that life isn't fair, I redirect that
argument back to you about your complaint that evolution is slower for
your sucky imap server.

maybe the reason the imap server is so slow is because no one bothers to
report bugs about it because they are too busy filing bugs against the
wrong project trying to get everyone else to just work around their
suckage rather than fixing the problem at the source.

> But, seriously, congratulations on the performance gains for Courier, 
> better than halving loading times is very impressive.

thanks ;-)

Jeff

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