Charles Marcus put forth on 5/10/2010 8:26 AM:
On 2010-05-10 8:48 AM, Stan Hoeppner wrote:
I'm thinking at this point that the cause of the problem is that I probably use Tbird in a way/methodology that the Tbird devs never anticipated, or discourages. It's seems clear, unfortunately, that their entire mindset is based on a FAT client that caches, indexes, and syncs all messages locally.
What is Tools > Options > Disk Space > Cache set to? I guess it is possible that if you set the cache too low it might cause problems...
It's set at 100MB. But recall I cleared out all the local stuff the other day (by hand at the command line). Afterward, I launched TB and accessed each IMAP folder. Tbird pulled 25k+ headers in under 30 seconds. Again, the problem is strictly the speed of pulling new message headers. And again, it appears all the time is wasted within Tbird running some kind of loop code, as there is zero network or disk activity on the client or the server.
Also, for Tools > Account Settings > Synchronization & Storage, have you told TBird to delete any messages under the 'To recover disk space ...' section?
I don't sync messages, so this setting is ignored. This setting only applies to local mbox files resulting from IMAP sync. It doesn't apply to index/cache files. Index/cache file records are automatically purged when you delete an IMAP message on the server, thus this setting couldn't apply to them regardless.
Again, the only problem is the speed of pulling new message headers from the INBOX. Everything else is lighting fast. The speed issue seems due to a code loop. It is not related to actual data transmission. The problem must be with the INBOX new message processing code in TBird and/or a setting that configures said code. My mission is find out exactly what that is.
-- Stan