209.48 KB, text/plain
237.85 KB, text/plain
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:188.8.131.52) Gecko/20100608 Thunderbird/3.1 The left column of Thunderbird is long enough to require scrolling for me. Mostly due to a large number of RSS feeds. With Thunderbird 3.0 and earlier, scrolling this pane was quite speedy. However, with 3.1, scrolling this pane is jumpy and results in 100% cpu usage. Steps to reproduce: 1. Subscribe to a number of RSS feeds 2. Slowly scroll the left pane up or down Actual results: 100% CPU usage. Jumpy scrolling. Expected results: Nominal CPU usage. Smooth scrolling.
Created attachment 454271 [details] Activity Montor sample while Thunderbird 3.0 is scrolling The obvious difference here is that the Thunderbird 3.1 sample has a large number of calls to XRE_GetFileFromPath , while 3.0 only has one.
I don't think this is limited to just RSS feeds. I have two IMAP accounts, one with 140 folders and a second with 160 folders. Scrolling on TB 3.1beta1 is painfully slow and laggy.
I can't reproduce this. Does it happen in safe mode? https://support.mozillamessaging.com/en-US/kb/Safe+Mode using nightly builds, can you narrow the regression to a short range or single day? http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/ ftp://ftp.mozilla.org/pub/thunderbird/nightly/2010/
I suspect this is all fine on the Mozilla trunk because in bug 506814 we started using native paths as the persistent descriptors instead of the mac alias stuff. But for 1.9.2, we're still doing that. What I don't see is that 3.0 behaved any differently from 3.1 in this regard, at least from looking at the code. In any case, I bet this is mac-specific.
Nick, are you on Mac? If so ... WD please test Mac nightly build at ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central-trunk/ and report results.
Wayne: Running latest nightly gives smooth scrolling. Just like 3.0 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:2.0b2pre) Gecko/20100701 Shredder/3.2a1pre
that would be consistent with what I said in #c5
(In reply to comment #6) > WD please test Mac nightly build at > ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central-trunk/ and > report results. Ah, yes - that appears to have fixed it. Both scroll wheel and scroll bar drag are back to their previous speeds. thanks!
WD, Nick, thanks for the feedback. WD, how many folders? Bienvenu, do you think the patch might acceptable for 1.9.2? (suspects not) is this behavior dependent on there being a large number of folders? (not duping) fixed (on trunk) by bug 506814
I have about 60 subscribed RSS feeds.
(In reply to comment #10) > do you think the patch might acceptable for 1.9.2? (suspects not) I suspect you suspect correctly. > is this behavior dependent on there being a large number of folders? I doubt it, other than the more folders you have, the longer you can scroll, and the slower it can seem. I can't say I understand this regression completely. Nick, do you have any extensions installed?
british english dictionary 1.19 + enigmail 1.1.2
I also have enigmail installed, however uninstalling it makes no difference with performance. 3.1 has slow scrolling on OSX with no extensions installed.
this still seems to be broken in TB 3.1.1. Was the fix committed to this version? The latest nightly works fine.
(In reply to comment #15) > this still seems to be broken in TB 3.1.1. Was the fix committed to this > version? The latest nightly works fine. details are in bug 506814. In short no, it's fixed only in gecko 1.9.3. 3.1 is based on gecko 1.9.2. And whether it will be fixed on 3.1, depends on how severe the impact is on using the UI - minor impact perf issues aren't likely to be accepted for 1.9.2
it's severe enough for me to make 3.1 unusable on a mid-2009 MBP / 2.8Ghz / 8G memory. Scrolling down through the folder pane is impossibly inaccurate because of the lag. And if you click to scroll (rather than drag-to-scroll), about 2/3 of the time it registers 2 clicks instead of one (maybe registering mouse-unclick as a separate scrollable event?), and you end up scrolling way too far.
WD, Nick, does this old trunk build resolve the Mac folder pane scroll slowness?? (please test with indexing disabled, and for safety make sure you use a TEST profile) ftp://ftp.mozilla.org/pub/thunderbird/nightly/2010/01/2010-01-01-06-comm-central-trunk/ Mike, Joe, Roland, do you also see this slowness on Mac?
Wayne: The version you link to is smooth as silk.
(In reply to comment #19) > Wayne: The version you link to is smooth as silk. Thanks. WD Is the right (message thread) pane is unaffected, correct? We should ask to get bug 506814 fixed in version 3.2 and perhaps v3.1
(In reply to comment #20) > Is the right (message thread) pane is unaffected, correct? Correct. The message thread is unaffected.
yep, not seeing this problem on 2010-01-01-06-comm-central-trunk. Scrolling is as quick as usual. I'm stuck using shredder at the moment, so it would be really good to go back to a stable 3.1 release.
(In reply to comment #18) > WD, Nick, does this old trunk build resolve the Mac folder pane scroll > slowness?? > (please test with indexing disabled, and for safety make sure you use a TEST > profile) > > ftp://ftp.mozilla.org/pub/thunderbird/nightly/2010/01/2010-01-01-06-comm-central-trunk/ > > Mike, Joe, Roland, do you also see this slowness on Mac? I don't see this on my 450MHz G4. Then again, (a) I don't have anywhere near the number of folders & feeds that the OP has, and (b) everything's "slow" anyhow. :) It does make me wonder, though, if it's x86-specific.
Just a note that this is definitely still not fixed in 3.1.7, though it's fine in Miramar Alpha 1. Would be really nice to have this fix back-ported to 3.1.x, as Thunderbird is almost unusable for me as is.
Just follow up to Gavriel's note, I am on 3.1.10 and the bug still exist in 3.1.X branch.
(In reply to Joe Sewell from comment #23) > It does make me wonder, though, if it's x86-specific. if it was related to bug 506814, no. It simply cites "Going through this stuff makes us hit Carbon file URLs and end up super slow."
Gavriel, Bart, do you see this in version 5 or newer? You shouldn't see it any more because of comment 5. (In reply to Gavriel State from comment #24) > Just a note that this is definitely still not fixed in 3.1.7, though it's > fine in Miramar Alpha 1. Would be really nice to have this fix back-ported > to 3.1.x, as Thunderbird is almost unusable for me as is. (In reply to Bart Swedrowski from comment #25) > Just follow up to Gavriel's note, I am on 3.1.10 and the bug still exist in > 3.1.X branch.
This seems to have regressed with Thunderbird 15. Perhaps not as bad when I originally filed the bug, but noticeably slower than 14.