Overview Description: The mailnews performance is very slow in Linux Commercial build. Some data collected 1. Time to open an IMAP Account after entering the password is ~4 minutes. 2. Time to read a message is ~25 seconds. 3. All other operations are relatively very slow. Steps to Reproduce: 1) Start Messenger. 2) Do any simple operations like read, send, etc. 3) Notice the performance. Build Date & Platform Bug Found: 1999-10-22-08-M11. Linux Commercial build. ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/1999-10-22-08- M11/netscape-i686-pc-linux-gnu.tar.gz Additional Information: 1. I tested all other linux commercial builds this week (10/18 to 10/21). Performance in these builds are ok.

Can we constrain this bug to IMAP performance? Changing the bug summary and reassigning to mscott.

The performance was slow for both IMAP and POP. Updating summary.

imap has been getting slower and slower on windows now too over the past week or two.

Adding daver to the cc list because he's seeing the same type of degradation on Windows. (I'm seeing it too)

Yep, this was happening on Thursday and Friday's build as well. I'm using NT. The CPU goes to 100% usage when I select my inbox. I wait about 45 seconds for the password prompt, then it goes off into another land while it tries to get new messages. CPU still at 100%. I can't use mail with this bug.

I've been seeing this too. Marking a message read is painful as well. On Linux, I can't even download my messages. It freezes after downloading anywhere from 25-90 of my 255 messages. I don't know if this is related. Sometimes I can't even open the folder but instead spends forever trying to locate it. On Windows, I don't seem to have this problem, but it is painfully slow. Unless the mac is blazingly fast, I'd remove the [pp].

Clearing the pp stuff. Scott your hanging problem on Linux is in a different bug: Bug #17065

If I comment out the msg status feedback calls at the lowest level (right before calling setAttribute), there is a ~50% speedup - we go from 45 seconds to 22 seconds to open my imap inbox. This implies that doing the progress meter and displaying status message consumes a lot of time.

That makes a lot of sense to me. When I was doing profiling, I noticed that those actions took a lot of the time for parsing a folder. I wonder if we are making more than one call to display the same line of status and if so, how many.

No, I'm pretty sure we're not doing that - I protect against that. My guess is that layout has gotten slow, or is invalidating more than it should (sorry Rick!). That's why it was slow in the past - it was causing an invalidation of the whole message window, which repainted every time.

Let me know if you guys need Quantify data on this. :-)

Just turning off the meteors saves 50% of the time - perhaps animated gifs have slowed down? Cc'ing pnunn, as a guess.

I've been seeing this performance degradation for a while, but in today's build, image performance seems to be pretty bad. All of my icons in the tree widget are in the state with the large box where the image isn't loaded yet for a while before the images actually get loaded. I don't recall this happening last week.

this started happening towards the tail end of last week - I wasn't sure if that was an image library problem or a layout problem. Or maybe necko :-(

Okay, it's definetly the animated gif for the meteor that's giving us problems. Disabling the meteors and then trying to bring up a password dialog took about 8 seconds on my machine vs. close to two minutes with the meteors turned on. There are possibly two contributors to this problem 1) I know some of the image lib code changed a lot Thursday and Friday. Performance could be effected there 2) I believe there were some changes last week to thread priorities giving the UI thread higher priority from other threads. If the animated gif code was intensive and now has higher priority than our imap thread....well that could explain why it takes so long for an imap event to get processed on the UI thread. David is checking in code as I type this to turn off the meteors for mailnews. Now we need to figure out the right owner for why we have problems with the meteros turned on. Pam do you think this might be you with animaged gifs?

Another interesting observation, if I switch to another program (nt-emacs in this case) things speed up and get going pretty fast.

The throbber/progress meter inefficiency is a somewhat known problem (see bug # 13131) but I still think this has gotten much slower than it was.

Okay, dougt just checked in some changes for me to fix the auto proxy peformance bottleneck that we were seeing with imap. The password dialog now comes up in a couple of seconds instead of a minute or two. So you should see this fix in the 10/27 release builds. The other performance problem was caused because of the throbber. As David mentioned, there is another bug tracking this issue and we have temporarily disabled the throbber in mailnews until it gets fixed. So I'm going to go ahead and mark this bug as fixed with the understanding that the performance bottleneck with the throbber is already a dogfood stopper bug.

Linux only on 11-04-08-M11 build: I reopen this bug since it took too long for reading message for Linux platform again(include IMAP, POP and News). Cc: myself.

Provide more info from last comments: Time to read a 1kb message is 36 seconds. Hardware/OS info is: 128 MB RAM / 200 MHz for Linux 6.0.

Clearing FIXED resolution due to reopen.

This regression came within the last 4 or 5 days. I haven't pinpointed the problem down exactly. It looks to me like most of the time is spent with necko and not layout. (i.e. time between the protocol and the networking layer) I wonder if the changes to give the UI thread higher priority is starving out the necko thread here. Maybe that's what's causing the problem? Or it could also be part of the issue where on linux the UI thread is running events from another thread's event queue.

I'm seeing this too, both on local and IMAP messages. Time to read a message jumped dramatically a week or two ago. It makes mail unusable.

M12, scheduled for 12/3 (mscott is busy with porkjockey work) change OS to Linux, put [PP] in the summary.Scott, does this bug need a dependency on something else?

If you turn on flashing on repaint, you'll see that we relayout and redraw all of the 3-pane window at least 5 or 6 times when you load a small message - I'm sure this is part of the reason loading a message is slow, especially on mac and linux.

David, your comment about repainting the 3-pane 5 or 6 times when displaying even a small message is very interesting. I wonder if our performance regression came about when incremental layout got turned on? Now that I think about it, the dates do match up. that is, we started seeing the message display time regressions about the time that incremental layout got turned on a couple weeks ago. Hmmm.....

*** Bug 18008 has been marked as a duplicate of this bug. ***

Just to summarize where we are on this. I have edited my unix build such that the progress meter and the throbber are turned off. This fixes most of the performance problems reported in this bug. Things work much faster for me. This is because it appears that changing the throbber or the progress meter is causing a repaint of everything between the throbber and the progress meter. I'm guessing that repainting the thread pane could be particularly slow if it is re-evaluating all of the style sheet rules that go into the thread pane. Turning progress and throbber off in our js code for linux made a huge difference for me. I'm not sure where to go with this bug next? It definetly depends on 13131. I'm going to mark this as a dependency on that bug and we'll see what happens after that problem gets fixed.

Repainting doesn't need to re-evaluate the style rules, does it? I though just reflow would require that, and only if something changed.

checked in fix.

suresh, pls verify in tomorrow's build.

Wow. Great improvement on Linux performance. Using 1999-12-01-13-M12 commercial build time taken to load a 10 KB message is 4.5 seconds (calculated on an average of 10 runs). Same machine configuration (166 Mhz, 64 MB RAM). Marking Verified.

Win32 is still slow though. Suresh will file a separate bug since this bug appears seems very "busy" with comments.