Bug 468888 - Terrible performance -- high CPU usage while doing XMLHttpRequests
Terrible performance -- high CPU usage while doing XMLHttpRequests
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-10-28 13:02 EDT by Tethys
Modified: 2018-04-11 05:25 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-27 09:25:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/proc/cpuinfo (1.10 KB, text/plain)
2008-10-30 13:47 EDT, Tethys
no flags Details

  None (edit)
Description Tethys 2008-10-28 13:02:30 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):

How reproducible:
Every time

Steps to Reproduce:
1. Open firefox
2. Go to http://www.igindex.co.uk
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.
Comment 1 Matěj Cepl 2008-10-28 18:14:36 EDT
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.
Comment 2 Tethys 2008-10-29 13:59:47 EDT
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
Comment 3 Matěj Cepl 2008-10-29 19:12:02 EDT
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.
Comment 4 Tethys 2008-10-30 06:36:16 EDT
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:


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.
Comment 5 Matěj Cepl 2008-10-30 13:01:07 EDT
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?
Comment 6 Tethys 2008-10-30 13:46:29 EDT
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,

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."
Comment 7 Tethys 2008-10-30 13:47:10 EDT
Created attachment 321965 [details]
Comment 8 Matěj Cepl 2008-10-30 18:29:21 EDT
(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
Comment 9 Matěj Cepl 2008-11-27 09:25:24 EST
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.


Note You need to log in before you can comment on or make changes to this bug.