[Dovecot] Thunderbird very slow startup, 1.2.11, mbox, postfix local delivery to /var/mail

[Stan Hoeppner]

Charles Marcus put forth on 5/7/2010 9:28 AM:
> On 2010-05-07 8:00 AM, Stan Hoeppner wrote:

>> It seems TB then spins at 100% CPU for 60+ seconds saying 
>> "Downloading header x of 300". When it hits ~300, then there is
>> finally network activity as TB seems to sort the messages into the
>> proper IMAP folders, which is lightning quick compared to
>> "downloading message headers".
> 
> The only other thing I can think of is some kind of AV on the local
> computer, but it seems like that would affect OE too - unless you had
> configured it to not scan OE connections...

I don't use any A/V plugin in TB, and TB is what is using 100% CPU while
downloading the new message headers.  All other processes are at 0% CPU.
The only other non Windows processes running all the time are the Sun Java
Quick starter and Java update scheduler.

>> I don't recall having this performance issue with dovecot 1.0.15.  Just in
>> case it's something I nurfed in my dovecot config, here's my dovecot -n
>> output.
> 
> It would be good if you could confirm this, but, I think that if its a
> config issue, its more likely a TB config issue (especially since OE
> seems to not have a problem) - too bad TB doesn't have a way to dump the
> config changes like dovecot/postfix...

Yeah, that would be nice.  The config editor does highlight all user defined
settings in bold though.

> Did you make any manual config changes to TB using about:config or
> applying manual changes to user.js?

The only TB change I recall making via about:config was to disable
condstore.  Since updating to 1.2.11, which fixes condstore support, I
reenabled it.

That said, I've made a number of about:config changes in Firefox, which,
IIRC, shares config info with TB.  However, the about:config changes I've
made to FF are all http tweaks, such as pipelining, etc, which shouldn't
affect TB.  I do have the TB CompactHeader and Enigmail plugins installed,
but I wouldn't think these would cause this slow header download issue, as
they deal with display.  AFAIK they aren't in play during new message header
downloads.

-- 
Stan