Re: [Evolution] Evolution takes very long to read IMAP folders

[Srikanth Madugundi <msrikant sun com>]

It is true that evolutions takes time to read mail boxes. But it is one time job. I hope that should not be a problem. what I am concerned more about is a new mail arrives with an attachment (say of size 2 MB). Evolution takes time opening this mail. It just displays the headers and no body, and we are confused if the mail contains any message or not.
If it is possible the Evolution could display the body and in background get the attachment while the user is reading the body of the message.

I tried searching if there is such a option saying "download attachment along with the mail", I couldn't find one. 
I guess this would be a nice feature.

Thanks
-srikanth

On Thu, 2002-06-13 at 17:50, Not Zed wrote:
> On Fri, 2002-06-14 at 06:42, Alexander Skwar wrote:
> > Hello.
> > 
> > I just tried out evolution 1.05 again.  I'm using the Mandrake
> > RPM package evolution-1.05-1mdk on a current MandrakeLinux cooker
> > system.
> > 
> > When I load some semi large mailboxes over an IMAP connection to
> > a courier IMAP 1.4.5 server running on localhost, Evolution
> > nearly always takes at least twice as long to read a given
> > mailbox as Mozilla 1.0 does - and mutt is almost always ~4 times
> > as fast as Evolution, but since mutt doesn't cache anything, it
> > always needs to reload the complete folder, so overall Evolution
> > will be fast that mutt.
> > 
> > Anyhow - why is it, that Evolution is so very slow in reading
> > IMAP folders?
>
> Becuase the imap code sux?  Uh.  Not entirely.
>
> 1. evolution gets all of the headers (not sure if the others do, mutt
> probably doesn't), which for most imap implementations isn't real cheap,
> and also means more network traffic.
> 2. evolution stores each header on disk, which in my testing slows
> things down quite a bit esp for bigger mailboxes (where bigger is >5K or
> so).
> 3. the imap code does suck, at least a bit.
>
> We get all of the headers mainly so 'vfolder on mailing list' is more
> reliable, and the threaded message display works more reliably too.  The
> information we use to calculate both are not part of the information
> obtained in the imap request (FETCH BODY) which was designed for
> 'getting enough info to display a list of messages'.  I'm not sure
> caching the headers on disk was really useful, we should probably throw
> them away and rely on the summary content, or store them some other,
> more efficient way (like a null mbox).
>
> There are also some overheads in evolution not related to imap at all,
> but the displaying of the list of messages, which start to impact more
> once you get above a few thousand messages.  We're looking at addressing
> these issues too, but they probably dont rate very highly in your
> timings anyway.
>
> I've been rewriting imap in my spare time to address some issues like
> this, but its not going terribly fast (and my spare time lately is worth
> more to me than better imap code!).  But if it sticks to still getting
> all (or even an 'interesting subset' of) headers, so that 'vfolder on
> mailing list' continues to work usefully, its still not going to be as
> fast as mutt, although it should be faster than currently.
>
> Might have to make it an option so users can decide what is more
> important to them - speed or features.
>
>
> > Here are the timings I've done:
> > 
> > Mandrake Changelog List
> > - 1902 messages
> > - 9 MB
> > -> mutt: 5 seconds
> > -> Mozilla: 10 seconds
> > -> Evolution: 20 seconds
> > 
> > Mandrake Cooker List
> > - 11574 messages
> > - 64 MB
> > -> mutt: 30 seconds
> > -> Mozila: 70 seconds
> > -> Evolution: 190 seconds
> > 
> > MySQL List
> > - 13136 messages
> > - 73 MB
> > -> mutt: 30 seconds
> > -> Mozilla: 70 seconds
> > -> Evolution: 190 seconds
> > 
> > The timings have been taken with a "stop watch" from the time I
> > clicked/opened the folder until the time the MUA was done with
> > reading.
> > 
> > Alexander Skwar
> > -- 
> > How to quote:	http://learn.to/quote (german) http://quote.6x.to (english)
> > Homepage:	http://www.iso-top.de      |    Jabber: askwar a-message de
> >    iso-top.de - Die günstige Art an Linux Distributionen zu kommen
> >                        Uptime: 16 hours 41 minutes
> > 
> > _______________________________________________
> > evolution maillist  -  evolution ximian com
> > http://lists.ximian.com/mailman/listinfo/evolution
>
>
> _______________________________________________
> evolution maillist  -  evolution ximian com
>     
http://lists.ximian.com/mailman/listinfo/evolution

-- 
---------------------------------------------------------------
Srikanth Madugundi                   srikanth madugundi sun com
Member of Technical Staff                      msrikant sun com
Sun Microsystems                     Hello: 2298989 Extn: 87497
Bangalore, INDIA
--------------------------------------------------------------