Red Hat Bugzilla – Bug 468888
Terrible performance -- high CPU usage while doing XMLHttpRequests
Last modified: 2018-04-11 05:25:44 EDT
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):
Steps to Reproduce:
1. Open firefox
2. Go to http://www.igindex.co.uk
30-35% CPU usage
1-2% CPU usage
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
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
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:
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)
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,
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
Created attachment 321965 [details]
(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.