Re: [Evolution] 1.4 Starting VERY slow with SSL/IMAP

[Not Zed <notzed ximian com>]

On Thu, 2003-07-10 at 03:13, Rob Snow wrote:
> Let me give the entire setup so I don't leave anything out: 
>  
> Server: 
> FreeBSD-Stable (4.8) 
> UW-IMAP 2002(a) SSL/Cleartext passwords 
> IMAP folders = ~/mail/ 
> UNIX format (flatfiles) 
> Celeron 850 + 768MB of RAM 
> 100Mbit 
>  
> Client: 
> Gentoo-stable (except for Evo and a couple of other userland apps) 
> Evo 1.4 (from the masked ebuild in portage) 
> Setup to connect forced SSL 
> Evo has the password 
> Athlon-XP 2.0GHz + 512MB RAM 
> 100Mbit 
>  
> The mail account in question has about ~360MB of mail in it, mostly under 
> ~/mail/Archives. 
>  
> Evolution takes around 60seconds from launch to become usable.  Kmail takes 
> ~5-10seconds on the same account, server, etc. 

Well, if you're doing things like vFoldering on any of the folders,
evolution might necessarily be having to do more work right off the bat,
e.g. checking all folders for new messages and fetching their headers. 
In that case the direct comparison wouldn't be valid.

We also get headers using a more complex query, because we use header
fields not available in the imap envelope query to do vFoldering on
mailing lists.  uw-imapd apparently bogs down with this, i think.

You could try running evolution with CAMEL_VERBOSE_DEBUG set to 1 in the
environment, that will dump the imap traffic, and might show up
something that doesn't look right ...

But bluntly, we know evolution's imap implementation is a pig, and hope
to replace it for 1.6 (but its a big task, particularly to distill the
features, and all of the server bugs we're working around in the current
code).  I also want to add some options, like if you don't care about
vfoldering on mailing list headers, you can tell it to use more
efficient imap queries to improve startup time.

> I will add that there are a few other files in the /mail/ directory due to my usage of 
> OpenWebMail as my prmary mail client at this time.  Those files are .db's, etc. (don't 
> imagine they are a problem, but including their existence for completeness) 

Shouldn't be unless its trying to list them as folders.