On Tue, 2006-04-04 at 10:15 -0300, Pedro Fernandes Macedo wrote: > Add then bug #336074 (RH #167805) to the previous one and you get a > pretty bad situation where you check all your old folders even when > you dont want them and you do it using the slowest method possible > (the above bug). > > Those two can be a bit problematic if you have an IMAP server that is > outside of your network and your link is a bit overloaded or you have > a lot of e-mail stored on the server. To put real numbers to 'a bit problematic'... Even after I fixed #336074 (RH #167805 -- filed September 2005, still in NEW state), it took two hours to start up for the first time when it was working over my DSL line, and it even took 23 minutes to start up when it was here in my house and connected via GigE to the IMAP server. It fetches every header for every mail in every active folder -- and without my patch for #336074 that would have been every folder in the system, not just the active folders. Whenever it reconnects, it updates its cache by downloading all new headers from the server. The cache in my ~/.evolution directory is about half a gigabyte, most of which is unnecessary. Each time it checks for new mail, it fetches the flags for every mail in every (active) folder -- instead of just issuing a single STATUS command for each (active) folder. For an idea of its runtime performance, see the graph from by my ISP: http://david.woodhou.se/what-evo-did-to-my-bandwidth-graph-2.png You can see when it was started up (remotely) at about 7:30 on Saturday night, and stopped just after 10:15 on Sunday morning. The periodic mail check is set to something like 12 minute intervals -- 5 checks an hour. You can see my _original_ remote startup at about 7pm on the first day of http://david.woodhou.se/what-evo-did-to-my-bandwidth-graph-elided.png along with the result on the latency for the next few days till it was killed (with a brief respite on the second day because I'd killed it to play with a potential fix). Again, that's with #336074 fixed so it's doing about 12 times less work than the 'stock' evolution packages would be doing. The ISP didn't have the shiny new graphs in place back then, so it didn't show upload and download bandwidth -- but it's still fairly clear. Then there's the one which makes it unusable for people who use wu-imapd and check 'show only subscribed folders' -- that's BZ #181805. These are probably the minimal fixes we need to turn it from an unusable pile of crap into just a suboptimal pile of crap: http://david.woodhou.se/what-evo-did-to-my-bandwidth-graph-2.png Gr. No, that's https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145314 in action. Let's try that again without trying to just select-and-middle-click like we can in any non-broken X application... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183219 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161397 -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
