Trunk builds are considerably worse compared to a 20080721 build in CPU and RAM usage even at startup with a big inbox (200,000 msgs) and when opening folders. It takes TB 2 min at 100% CPU and 800 MB RAM at startup *before* even showing the first window (!). Clicking on another (small) folder and again on inbox takes another 2 minutes and against increases the RAM usage to 1.3 GB. (This is on 32bit Linux - I dropped 64bit because of Thunderbird.) More detailed numbers see bug 296453 comment 46. I don't remember it being as bad in the ealier build. From what I remember, it took 10-20s and 200-300 MB RAM to show the first window; after 2 days, TB used less than 1 GB RAM. Bienvenu mentions bug 243631 as possible slowdown reason. I have no idea whether that's the cause for this bug.
(In reply to comment #0) > Trunk builds are considerably worse compared to a 20080721 build in CPU and RAM personally I've found it to be better, and more steady in those two respects. but I don't doubt your experience. narrowing the regression range would really help
More info on my setup: * IMAP on Cyrus server on local private network * 200,000 msgs in Inbox, as said * Almost everything spam (due to bug bug 296453), which means subjects often repeated, and From varying a lot and not in addressbook (if relevant for bug 243631).
The only change that has been checked in for bug 243631 should only affect when you actually display a message (i.e. view the headers). We haven't checked in anything that will affect the message view yet.
If the current state is actually a non-trivial regression from Tb2, this should block. But we're gonna need someone to do so comparison timings in order to find that out. Adding qawanted. Feel free to renominate in once that's happened.
I noticed that this is actually not a regression, but caused by me using a different sort criteria in thread pane. Marking INVALID and filed new bug 452944.