On Wed, 2003-03-12 at 16:49, Mark Crispin wrote: > On Wed, 12 Mar 2003, David Woodhouse wrote: > > After all, although Evolution is taking 10 seconds to open certain > > folders at the moment because it's re-downloading flags, it doesn't > > actually _need_ all of those flags > > Right. So why does it need to download all of them? Note that the SEARCH > command can often be used in lieu of having the flags locally.
It currently tries to download all of them because it's broken and we can't update the GUI tree widget as and when items become visible. That is an implementation detail which does need fixing. That fact doesn't change the fact that not being able to _cache_ flags is also suboptimal; each problem merely exacerbates the other. But SEARCH is a very good idea for optimising Evolution's _current_ behaviour -- since Evo only needs to know (IIRC) about \Seen and \Answered, those two search commands are likely to be a _lot_ faster than just fetching all the flags. And it can probably be done in Evo's IMAP back end without actually having to have rewritten all the rest of the mailer (yet). Thanks for the suggestion. For my linux-kernel mailing list folder (and bearing in mind that 'ssh $MAILHOST /bin/true' takes three seconds on its own... $ ( time echo -e "000 select inbox.lists.l-k\\n001 search (unseen)\\n002 search (answered)\\n003 logout\\n" | ssh $MAILHOST imapd ) 2>&1 | egrep real\|EXISTS * 5272 EXISTS real 0m4.095s $ ( time echo -e "000 select inbox.lists.l-k\\n001 fetch 1:5272 (flags)\\n002 logout\\n" | ssh $MAILHOST imapd ) 2>&1 | grep real real 0m25.027s Admittedly that's the folder that's going to give the _best_ ratio, since it has many messages, few of which are unseen and even fewer of which are answered. But then again, that's the one I care about most, because that's the one that's been taking 20-odd seconds to open :) > > I prefer to do the same. The startup time is far from negligible. But I > > got out of the habit of leaving them running while using wu-imapd, > > because the imapd would keep killing itself if two clients looked at the > > same folder at the same time. > > That's an artifact of the traditional UNIX mailbox format. Try the mbx > format. I tried MH, and I didn't like the loss of unseen-sequence with wu-imapd. Mail I read from pine or with an imap clients wasn't showing up as read in other MH-capable stuff. Now I'm trying maildir. Maybe I'll try mbx next :) > > It's about five seconds per page (19 mails) for me this morning. How > > does the size of the envelope matter -- we're only displaying four > > fields. Are we downloading headers we don't actually need? > > Pine uses envelopes, not headers. If it's taking 5 seconds to get 19 > normal sized envelopes then something else is wrong. I'll investigate precisely what it's doing. > "Session" is defined in RFC 2060, and refers to the period that a mailbox > is selected. Ah; OK. Since pine tends to restart a session each time I change mailbox, that's not actually caching for as long as I'd like it to. I tend to flit between mailboxen a lot. -- dwmw2
