I'm also a UW-IMAP user and was following this thread closely as i was also rather disappointed with evo 1.2 speed...
When u mentioned vFolders, i suddenly remembered that about the time I upgraded to 1.2 I also "experimented" with setting some vfolders to point to IMAP sources (for fun, i didn't really need vFolders on IMAP, as i've got good server side filtering going).... When I got rid of those pesky vFolders on IMAP... It made a HUGE difference. Selecting folders and messages is now many times faster. Me say... Evolution good! vFolder on IMAP ...my bad! Keep up the good work fellas... Evolution is a wonderful client. TT On Thu, 2002-11-21 at 06:23, Jeffrey Stedfast wrote: > On Wed, 2002-11-20 at 12:45, Scott Otterson wrote: > > Jeff, those are great numbers but I suspect the test isn't measuring the > > thing I'm talking about. What I'm talking about is amount of time > > evolution spends rechecking message headers and updating vfolders. For > > example, I just did this: > > ah, so now it's vFolders... > > > > > - started evolution > > - waited for the INBOX to show up (lots of messages about vfolders > > scanning for new headers) > > - open an email > > - delete that email > > - click on a different email header > > - again, I see a bunch of messages about scanning for new headers, etc. > > > > The delay for the 2nd check is about as long as when I first started > > evolution. I haven't yet figured out when evolution decides to go > > through all this checking and rechecking but it seems to be quite a lot > > more often than 1.08. This really makes evolution harder to use on a > > slow modem connection. > > > > > > Can you think of a way to test this aspect? Do you think that the > > checking and rechecking is because of evolutions's interaction with UW > > IMAP v.s. other kinds of IMAP? If so, the problem is solvable because > > the mozilla IMAP doesn't spend this much time checking and rechecking. > > what I don't understand is why you are comparing Evolution's > vFolder-over-IMAP speed to Mozilla's plain IMAP speed. Of course > Mozilla's plain IMAP is gonna be faster. > > vFolders are going to be much slower than normal physical folders, > especially on IMAP. > > As NotZed said, can you open a bugzilla bug about "vFolders are slow > over IMAP on dialup" and then attach your vFolder rules, IMAP server > type, and rough message-counts/sizes? Maybe even a timed results for how > fast stuff loaded in 1.0.8 compared to 1.2.0? As far as I know, this > should all be faster... but it'd be good to get times to compare. > > I'm not sure why NotZed thought you were getting a deadlock. Are you? > > In the meantime, I suggest you stop using vFolders and instead setup > server-side filtering. This will make your experience *much* faster I > think. > > Jeff > > > > > Scott > > > > On Tue, 2002-11-19 at 17:56, Jeffrey Stedfast wrote: > > > Since no one wants to listen to me, I've spent the past few hours > > > building Evolution 1.0.8 and deps on my Celeron 400 box at home here (a > > > multitude of hops away from our IMAP Courier server) and did the > > > following: > > > > > > - killev > > > - rm -rf ~/evolution > > > - evolution > > > - create imap account - left on all default options (except I had to > > > turn on SSL). These options are as follows: > > > > > > [ ] Automatically check for new mail ... > > > [X] Check for new messages in all folders > > > [X] Show only subscribed folders > > > [ ] Override server-supplied namespace > > > [ ] Apply filters to new messages in INBOX > > > > > > - select local Inbox folder (so that the next time we start up it will > > > not load any IMAP folders, shouldn't be an issue but ah well) > > > - close evolution > > > - killev; evolution > > > - select [EMAIL PROTECTED]/INBOX/bugzilla > > > - immediately start stopwatch > > > - wait for message-list to load > > > - stop stopwatch immediately > > > > > > The results I got were as follows: > > > > > > Evolution 1.2.0: time = 4:25:48 > > > Evolution 1.0.8: time = 10:09:75 > > > > > > Seems to me that Evolution 1.2.0 is quite a bit faster than Eolution > > > 1.0.8 to me... more than 2 times faster in fact. > > > > > > Since you come from u.washington.edu, I suspect you probably use > > > uw.imapd, which may explain your problem - uw.imapd is known to be > > > extremely inefficient. I would suggest you install a faster imap server > > > such as Courier imapd or (the even faster?) Cyrus imapd. > > > > > > Jeff > > > > > > On Tue, 2002-11-19 at 20:23, Not Zed wrote: > > > > On Wed, 2002-11-20 at 10:29, Scott Otterson wrote: > > > > > OK, sounds good. But, as I understood you this morning, you were > > > > > convinced that the PPP problem did not exist. > > > > > > > > I've dont plenty of testing with disconnecting, and it works fine. It > > > > takes a while and eventually times out. If i reconnect the network, it > > > > just keeps going again. > > > > > > > > > Just to make sure we're talking about the same thing, what's the number > > > > > for the open bug on PPP disconnects causing an IMAP hang? > > > > > > > > ?? > > > > > > > > IMAP and POP are separate. > > > > > > > > There might be some threading contention where a thread is 'busy' > > > > waiting for a timeout, but it isn't hanging. > > > > > > > > > > > > > Scott > > > > > > > > > > On Tue, 2002-11-19 at 14:22, Jeffrey Stedfast wrote: > > > > > > they are 1) unrelated and 2) already reported. > > > > > > > > > > > > Jeff > > > > > > > > > > > > On Tue, 2002-11-19 at 17:16, Scott Otterson wrote: > > > > > > > Why not? It's clear that there's a bug in evolution and that it's not a > > > > > > > fundamental flaw with Linux. > > > > > > > > > > > > > > Now, if the stop button bug and the PPP-disconnect-hang bug are > > > > > > > manifestations of the same problem, then I agree that it doesn't make > > > > > > > sense to file a new one -- that is, if there is a non-closed stop button > > > > > > > bug and if it is known that these are really the same problem. > > > > > > > > > > > > > > Are both these things true? > > > > > > > > > > > > > > Scott > > > > > > > > > > > > > > On Tue, 2002-11-19 at 13:33, Jeffrey Stedfast wrote: > > > > > > > > please do not submit new bug reports, thanks. > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > On Tue, 2002-11-19 at 16:15, Scott Otterson wrote: > > > > > > > > > Yes, Ettore, you're right about the stop button not working -- and > > > > > > > > > there's at least one bug on it but it was closed as fixed even >though it > > > > > > > > > wasn't. > > > > > > > > > > > > > > > > > > Is the stop button problem also causing the PPP-disconnect-induced > > > > > > > > > hangs? Or should I file a separate bug? Anyway, you're right that >this > > > > > > > > > isn't a problem with Linux: Mozilla on Linux handles PPP disconnects > > > > > > > > > just fine. > > > > > > > > > > > > > > > > > > Scott > > > > > > > > > > > > > > > > > > On Tue, 2002-11-19 at 11:38, Ettore Perazzoli wrote: > > > > > > > > > > On Tue, 2002-11-19 at 13:12, Jeffrey Stedfast wrote: > > > > > > > > > > > > On reading your response, my first thought was, "Boy, linux >must be > > > > > > > > > > > > lame," because on Windows, nothing hangs when you lose your >PPP -- not > > > > > > > > > > > > outlook, not mozilla, not anything as far as I know. > > > > > > > > > > > > > > > > > > > > > > wonderful about those win32 apis for finding out when the >connection > > > > > > > > > > > goes down. Not available on linux. > > > > > > > > > > > > > > > > > > > > Having the Stop button working properly in all cases in the mailer >would > > > > > > > > > > be a good starting point though. ;-) > > > > > > > > > > > > > > > > > > > > It is true that we have a bug there, and it can be fixed, and >there is > > > > > > > > > > no reason to blame Linux for it. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Ettore Perazzoli <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > evolution maillist - [EMAIL PROTECTED] > > > > > > > > > http://lists.ximian.com/mailman/listinfo/evolution > > > > > > > > -- > > > > > > > > Jeffrey Stedfast > > > > > > > > Evolution Hacker - Ximian, Inc. > > > > > > > > [EMAIL PROTECTED] - www.ximian.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > evolution maillist - [EMAIL PROTECTED] > > > > > > > http://lists.ximian.com/mailman/listinfo/evolution > > > > > > -- > > > > > > Jeffrey Stedfast > > > > > > Evolution Hacker - Ximian, Inc. > > > > > > [EMAIL PROTECTED] - www.ximian.com > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > evolution maillist - [EMAIL PROTECTED] > > > > > http://lists.ximian.com/mailman/listinfo/evolution > > > > > > > > > > > > _______________________________________________ > > > > evolution maillist - [EMAIL PROTECTED] > > > > http://lists.ximian.com/mailman/listinfo/evolution > > > > -- Ted Targosz Business Development/Operations Manager JobStreet.com Phone: 604-6445912 Hand Phone: 6012-2063600 Fax: 604-6428653 email: [EMAIL PROTECTED] _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
