Description of problem: Firefox has unacceptably high CPU usage. This is particularly noticable on sites that make XMLHttpRequests. Version-Release number of selected component (if applicable): firefox-3.0.2-1.fc9.x86_64 How reproducible: Every time Steps to Reproduce: 1. Open firefox 2. Go to http://www.igindex.co.uk 3. Actual results: 30-35% CPU usage Expected results: 1-2% CPU usage Additional info: This was first spotted on an internal site at work that was sucking 60+% of my CPU time. Other people in the office can view the same site with negligible CPU usage. For a test case, http://gmail.com uses 20% or so when just sat idle, and http://www.igindex.co.uk uses around 35%, again just sat idle on the front page. As an additional data point, my Firefox CPU usage was around 30% while filing this bug, with a single tab open, and nothing else running on the box other than Pidgin and a couple of xterms. I have plenty of memory free, and I have no Firefox extensions loaded. This is making Firefox unusable for many sites that I need for my work.
I don't see any problems when tried myself. Two things to check: 1) try to run firefox -safe-mode If you cannot reproduce the problem with this option (which basically switches off all plugins and extensions), then the problem is not in firefox but in some plugin or extension. Try to remove them all and then add one-by-one until you find the one, which make the trouble. 2) If you still reproduce the problem even in safe-mode, try to download upstream binary from http://www.mozilla.com/products/download.html?product=firefox-3.0.3&os=linux&lang=en-US (yes, they have only 32bit version, and you will have to install not only some .386 packages, but some compat-* libraries as well) If you cannot reproduce it with the upstream binary, it is our problem, otherwise I will file it for you upstream and follow the resolution there.
Yep, reproducible in both the Fedora version and the upstream one, with or without --safe-mode (the latter does reduce the CPU usage a bit, but it's still too high). As a good demonstration of the problem, go to http://bugzilla.redhat.com, select "Search existing bug reports" -> "Advanced search". Then choose the "Fedora" classification, the "Fedora" product, and watch the CPU hit 100%. Wait a bit, and Firefox asks to stop the script because it's not responding.
Bad reproducer: a) yeah, we know that Javascript in Firefox is not multithreaded and quite often pushes CPU to 100%. Nothing interesting here -- if you want to help with it, you should probably go to the bugzilla.mozilla.org b) clicking on Fedora in the search page make Firefox build a listbox with 8000+ items in it (that's the current number of components in Fedora) -- yeah, it takes a little bit of time. Closing this as NOTABUG. Please, reopen if you have better reproducer.
Yeesh. I'm getting *really* fed up with the Fedora bug tracking system. It seems that nearly every bug I report is almost immediately closed as NOTABUG, despite being valid bugs. That's not a good way to encourage community participation. Firstly, the RH bugzilla page uses more CPU on my system than it does on other machines. On others, it's slow and CPU hungry while it populates the listbox. On mine, it's sufficiently slow that firefox warns that the script is not responding. Secondly, I already gave two example sites that cause abnormally high CPU usage in the original bug report: http://gmail.com http://www.igindex.co.uk Sadly, the best indicator of the problem is an internal only site that works fine for others around the office (including on other F9 boxen), but prompts much higher CPU usage on my box, and becomes unusably slow.
OK, the problem is that I really cannot reproduce it here (both gmail.com and igindex.co.uk just work for me), and that's difficult to analyze bug which isn't visible here. Let me try couple of ways how to make more clear in the situation (and I still believe that you would get better help upstream at bugzilla.mozilla.org): a) how are other X applications fast/slow? We have reports that some graphic adapters can produce very slow repainting with some configurations. (try for example switching between pidgin with plenty of conversations in different tabs and evolution on two desktops) b) concerning the speed of Javascript itself -- try to run Javascript speed test on http://dromaeo.com/ Could you return as the URL of the result (will be on the top of the webpage of dromaeo.com when tests finish)? c) and of course, what is the CPU of your machine (attach /proc/cpuinfo)? How much RAM you have?
I know that the problem is specific to my machine, so I don't necessarily expect you to be able to reproduce it. Indeed, I even stated in the original report that others in the office don't have the same problem. Other X applications are pretty fast. I have no noticable performance problems with any of them. Most applications are pretty good with repainting, too. Firefox is the exception there, being noticably slower to repaint, but probably no worse than other large applications (e.g. gnumeric with a fairly large spreadsheet). It's still back and ready to go within a couple of seconds, though. Javascript speed test results: http://dromaeo.com/?id=50158 The hardware is dual Opteron with 2GB RAM. Not massively high spec by today's standards, but more than adequate. I'd probably have filed it upstream by now were it not for the fact that you said in comment #1: "I will file it for you upstream and follow the resolution there."
Created attachment 321965 [details] /proc/cpuinfo
(In reply to comment #6) > I'd probably have filed it upstream by now were it not for the fact that > you said in comment #1: "I will file it for you upstream and follow the > resolution there." So, that's misunderstanding -- please, go ahead and file this bug upstream (and let me know the bug ID#). Thank you very much
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.