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: [EMAIL PROTECTED] > > iso-top.de - Die g�nstige Art an Linux Distributionen zu kommen > > Uptime: 16 hours 41 minutes > > > > _______________________________________________ > > evolution maillist - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/evolution > > > _______________________________________________ > evolution maillist - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/evolution > -- > --------------------------------------------------------------- > Srikanth Madugundi [EMAIL PROTECTED] > Member of Technical Staff [EMAIL PROTECTED] > Sun Microsystems Hello: 2298989 Extn: 87497 > Bangalore, INDIA > -------------------------------------------------------------- _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
