Closed
Bug 409757
Opened 17 years ago
Closed 8 years ago
High CPU use when viewing comments at CNN.com
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: schapel, Unassigned)
References
()
Details
(Keywords: perf, regression)
Reproducible: Always Steps to Reproduce: 1. Go to http://www.cnn.com/2007/SHOWBIZ/TV/12/20/nickelodeon.spears.ap/index.html?iref=newssearch 2. Scroll down to near the bottom of the page and click the Next 25 comments link 3. Repeat step 2 two or three times Quickly the CPU usage reaches 99% and Firefox's user interface locks up. This was first reported at <http://forums.mozillazine.org/viewtopic.php?t=615017> and is explained as a regression from Firefox 1.5 that is present in Firefox 2 and Firefox 3.
Updated•17 years ago
|
Comment 1•17 years ago
|
||
Regression window is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-08-03+07%3A00&maxdate=2006-08-04+07%3A00 On Vista it is not as clear, doesn't really hang but gets only very slow, if you are patient, it loads finally. Caused by bug 345736? JS bug that was also checked in on branch.
Blocks: 345736
Comment 2•17 years ago
|
||
(In reply to comment #1) > Regression window is > http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-08-03+07%3A00&maxdate=2006-08-04+07%3A00 > On Vista it is not as clear, doesn't really hang but gets only very slow, if > you are patient, it loads finally. > Caused by bug 345736? JS bug that was also checked in on branch. Sorry, need more evidence. That bug's patch is to the JS parser and it does not lead to lengthy loops. It affects code enabled only by opt-in versioning (JS1.7, let as a context-sensitive keyword). I think we need a back-out from the guilty hook that we can prove caused this bug. /be >
No longer blocks: 345736
Comment 3•17 years ago
|
||
Did also a check on the branch and there are 4 bugs in common: bug 330689, bug 346936, bug 336592, bug 345736.
Results due to a patch to the fix for <a>Bug 347054 <href=https://bugzilla.mozilla.org/show_bug.cgi?id=345736></a> – crashes finalizing plugin scriptability objects inside js_GC [@ _PR_MD_ATOMIC_DECREMENT] [@ _PR_DarwinPPC_AtomicDecrement()] [@ 0x6c707538] (edit)
The thread that is causing excessive CPU usage seems to be firefox.exe!jpeg_fdct_islow
A smaller regression window on Mozilla 1.8 branch can be found and is http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-08-04+02%3A40&maxdate=2006-08-04+09%3A00&cvsroot=%2Fcvsroot I am not sure, but the sun calendar event in mozilla/calendar/prototypes/wcap/sun-calendar-event-dialog.js could be making excess eventlistener calls in v1.1.2.6: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/calendar/prototypes/wcap&command=DIFF_FRAMESET&file=sun-calendar-event-dialog.js&rev1=1.1.2.5&rev2=1.1.2.6&root=/cvsroot
Good BuildID on mozilla_1_8 branch is 2006080403 and problem one is 2006080409. If you copy the browser.manifest file in firefox\chrome from 2006080403 and paste it into newer version(s), the problem seems to be resolved/worked around. The ordering of first 3 declarations that works good is: content browser jar:browser.jar!/content/browser/ xpcnativewrappers=yes overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul content branding jar:browser.jar!/content/branding/ xpcnativewrappers=yes the one that causes problems is: content browser jar:browser.jar!/content/browser/ xpcnativewrappers=yes content branding jar:browser.jar!/content/branding/ xpcnativewrappers=yes overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul
Opening the original poster's CNN link and clicking next 25 a couple times did cause my Firefox 2.0.0.14 to use up 50% of the CPU (on my dual core Intel Core 2 Duo) initially, but even if I switch back to that still-open window, it no longer takes up much of the CPU (though some) However... the same thread "FIREFOX.EXE!jpeg_fdct_islow" will eventually eat up 50% of my CPU when I open enough windows+tabs - every time. I inevitably open up a fair number of windows+tabs, and always (lately, not sure if it was doing it *immediately* after my clean Win XP Pro SP2 (all patched) install or not, but surely soon after, if not immediately) I've seen a number of other posts on the forums and stuff, but no apparent solution or work-around or anything like that. Is there any, that anyone knows of? I don't know if I can help any further than the above info and possibly testing. I can debug a simple C, C++, C#, etc. prog, but I'm not sure I could even get Firefox to compile under windows, let alone debug it. (since it probably won't compile under Visual Studio 2005/2008) I would recommend that someone immediately go to the code and replace the "FIREFOX.EXE!jpeg_fdct_islow" with a "FIREFOX.EXE!jpeg_fdct_isFAST" ! (j/k! (sorry!))
Comment 9•16 years ago
|
||
(In reply to comment #8) > Opening the original poster's CNN link and clicking next 25 a couple times did > cause my Firefox 2.0.0.14 to use up 50% of the CPU (on my dual core Intel Core > 2 Duo) initially, but even if I switch back to that still-open window, it no > longer takes up much of the CPU (though some) those steps WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042305 Minefield/3.0pre
Comment 10•16 years ago
|
||
I tracked down this issue, and it looks like it's caused by the spell-checker module. If you turn it off from Tools->Options->Advanced->"Check my spelling as I type" it no longer causes the high CPU usage in that CNN webpage. Try it yourself.
Comment 11•16 years ago
|
||
Ref comment #10, indeed.. turning off spell-check does fix the hang/high CPU use and you can load the next 25 comments as fast as you want, no hang. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008051502 Minefield/3.1a1pre Firefox/3.0 ID:2008051502
Comment 12•8 years ago
|
||
The original URL that was provided with this bug is not available anymore. I tested this scenario with the below URL on CNN that contained several hundred comments and I loaded several of them one by one but did not see any substantial increase in CPU usage by firefox.exe even with discussed "spell check" configuration checked. It remained below 5% on an Intel Core I7-4810MQ CPU @2.80 Ghz box. URL tested: http://www.cnn.com/2016/04/06/opinions/presidential-race-after-wisconsin-opinion-gergen/index.html Tested on: Name Firefox Version 46.0b4 Build ID 20160322075646 User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 Closing the defect as "RESOLVED - WORKSFORME".
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Comment 13•8 years ago
|
||
(In reply to Kanchan Kumari QA from comment #12) > The original URL that was provided with this bug is not available anymore. I > tested this scenario with the below URL on CNN that contained several > hundred comments and I loaded several of them one by one but did not see any > substantial increase in CPU usage by firefox.exe even with discussed "spell > check" configuration checked. It remained below 5% on an Intel Core > I7-4810MQ CPU @2.80 Ghz box. > > URL tested: > http://www.cnn.com/2016/04/06/opinions/presidential-race-after-wisconsin- > opinion-gergen/index.html > > Tested on: > > Name Firefox > Version 46.0b4 > Build ID 20160322075646 > User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 > Firefox/46.0 > > > Closing the defect as "RESOLVED - WORKSFORME". I do not know if this can be closed - because on CNN, there is no longer any comments section! So the underlying issue could very well exist!!
You need to log in
before you can comment on or make changes to this bug.
Description
•