On Thu, 2002-11-21 at 04:15, 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: > > - 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.
This could be anything, it definetly isn't the tcp code. Its probably a vfolder or imap thread deadlock or something like that. Not much use discussing it here, you need to create a bug, and attach a backtrace of all threads of evolution-mail when it is in a solidly hung state. _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
