GNOME.org
 

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

On Fri, 2002-06-14 at 13:25, Srikanth Madugundi wrote:

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.


Well afaik it should already be doing it, but obviously its not, or what
its doing isn't enough.

The header is on-disk, so its instantly shown, it then downloads the
message structure - which can be (*very*) slow via remote link - the
current imap code cannot process pipelined requests at all, so all
requests are 1 at a time.  And then it downloads each part as it is
needed, in the case of multipart messages it should display the body
before it goes to download the attachment (if it does at all), although
perhaps it depends on the type of attachment it is (e.g. inline,
multipart/related, etc).

IMHO showing a header and a little busy box down the bottom of the
window is a lot better than just showing a totally empty box.


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
--------------------------------------------------------------
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]