Bug 518515 - firefox horrible performance degrades user experience
Summary: firefox horrible performance degrades user experience
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 12
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-20 16:44 UTC by William Lovaton
Modified: 2018-04-11 12:08 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-27 23:54:10 UTC


Attachments (Terms of Use)
Simple test case for firefox performance (8.25 KB, text/html)
2009-08-20 16:59 UTC, William Lovaton
no flags Details
valgrind's output (995 bytes, text/plain)
2009-12-25 06:46 UTC, William Lovaton
no flags Details


Links
System ID Priority Status Summary Last Updated
Mozilla Foundation 536910 None None None Never

Description William Lovaton 2009-08-20 16:44:27 UTC
Description of problem:
After installing Fedora 11, the new version of Firefox has serious performance problems compared to Firefox 3.0 in Fedora 10.

I am a web developer and some pages of an enterprise application I'm working on are showing serious performance degradation while being used.  The problem is not during the page loading or page rendering but while the user is interacting with the form elements in the web page.  Every once in a while, when the user tries to fill in a form input (eg. text box, radio button, select or check box) the browser freezes for about 3 or 5 seconds consuming 100% of the CPU, it doesn't happens all the time but often enough to be very annoying.

The problem is specially bad with big and complex pages, for example, I have a web page with well over 700 form elements (including hidden input elements) and some of the elements have JavaScript code used to validate input data or to perform calculations while the user is typing.

But the great news is that I managed to make a simple test case with 100 check boxes and with no JavaScript at all.  I'll attach the test case later.

Version-Release number of selected component (if applicable):
As I am a web developer I installed addons like LiveHTTP Headers and Firebug, but I uninstalled everything for the test including the Flash plugin and the Java plugin, so this is basically the simplest installation of Firefox ever.

[root@nalwalovaton ~]# rpm -qa *xulrun* *firefox* *mozilla* *flash* *plugin*
plymouth-plugin-label-0.7.0-0.2009.05.15.1.fc11.i586
xulrunner-1.9.1.2-1.fc11.i586
setroubleshoot-plugins-2.0.18-5.fc11.noarch
gstreamer-plugins-flumpegdemux-0.10.15-6.fc11.i586
alsa-plugins-pulseaudio-1.0.20-2.fc11.i586
mozilla-filesystem-1.9-4.fc11.i586
plymouth-plugin-two-step-0.7.0-0.2009.05.15.1.fc11.i586
anaconda-yum-plugins-1.0-4.fc11.noarch
gedit-plugins-2.26.1-1.fc11.i586
nspluginwrapper-1.3.0-6.fc11.i586
gdm-plugin-fingerprint-2.26.1-13.fc11.i586
gstreamer-plugins-bad-0.10.13-3.fc11.i586
firefox-3.5.2-2.fc11.i586
PackageKit-gstreamer-plugin-0.4.8-2.fc11.i586
gstreamer-plugins-base-0.10.23-3.fc11.i586
totem-mozplugin-2.26.3-1.fc11.i586
gstreamer-plugins-good-0.10.15-4.fc11.i586
yum-plugin-fastestmirror-1.1.22-1.fc11.noarch
PackageKit-yum-plugin-0.4.8-2.fc11.i586
gstreamer-plugins-ugly-0.10.12-1.fc11.i586


How reproducible:
Use a big web form with several elements and watch the CPU usage in top, I'll explain it in detail when I attach the test case later.

Actual results:
Firefox sometimes block unexpectedly for a few seconds consuming 100% of the CPU with no apparent reason.

Expected results:
Firefox should have better performance, specially since that is one of the big new features in the latest release.

Additional info:
This problem also triggers in some other ways, sometimes when you scroll the page with the mouse wheel, it freezes for a little while and then starts scrolling abruptly.  The other way is when you change the focus of the window using Alt + Tab and when you go back to Firefox it freezes for a while until it redraws the window properly.

As I said before this doesn't happen all the time but often enough to be incredibly annoying.

Also, remember using a not so powerful CPU so you can see the effect, right now I'm using Intel(R) Pentium(R) 4 CPU 2.80GHz Dual Core (or HT since I see two CPUs in gnome-system-monitor) which is by no means a weak CPU.  I still can see this problem at home with an Intel Core 2 Quad 2.4 GHz.

Comment 1 William Lovaton 2009-08-20 16:59:39 UTC
Created attachment 358136 [details]
Simple test case for firefox performance

The test is simply a web page with a form containing 100 check boxes.

Steps to reproduce:
1. Download the HTML page in your local filesystem
2. Open the file with Firefox
3. Open top in a terminal window
4. Change it to refresh every second (press "s", then "1" and then Enter)
5. Order the list by memory usage so Firefox is always at the top (press "m")
6. Click through several check boxes back and forth quickly, after a few seconds it freezes for a second while the CPU starts climbing to 100%, after the freeze the check box is checked or unchecked accordingly.
7. You can also reproduce the problem by clicking the same check box over and over until it freezes.

As I said in the first post you can also try to trigger this problem by scrolling with mouse wheel or by changing the focus back and forth with Alt + Tab.

For the test my computer was completely idle with top showing 99% or 99.5% of idle time.

If it's still difficult for you to reproduce this problem trying increasing the number of check boxes to 200 or 300.

Possible suspects:
1) I always thought it was a Pango problem since font rendering is always complex and there is already a history of Firefox being slow because of Pango.  But I don't think this is the case.

2) May be the spell checker is having problems with such a huge number of input elements.  I'll try to redo the test with spell checking disabled.

Comment 2 William Lovaton 2009-12-13 18:17:42 UTC
The situation seem to be improved in Fedora 12 a little bit but the test still applies.  It is very common to be browsing around and all of a sudden the browser blocks for a few seconds doing something with the CPU.

The problem seems to be very common:
http://www.gnome.org/~michael/blog/2009-12-03.html

Comment 3 Matěj Cepl 2009-12-14 10:56:51 UTC
Are you able to reproduce this with the upstream binary from www.mozilla.com?

Comment 4 William Lovaton 2009-12-15 11:03:46 UTC
Yep, I downloaded the latest binary from mozilla.com and I can see the same problem there.

Comment 5 Matěj Cepl 2009-12-16 00:47:43 UTC
I will file your bug upstream, but could we get also spec for your computer, please? I cannot reproduce this on my notebook (arguably beefy, dual core 2.5GHz,4GB RAM).

Comment 6 William Lovaton 2009-12-17 20:27:16 UTC
(In reply to comment #5)
> I will file your bug upstream, but could we get also spec for your computer,
> please? I cannot reproduce this on my notebook (arguably beefy, dual core
> 2.5GHz,4GB RAM).  

Matej, the problem is a lot more obvious on a low spec computer.  My laptop is a Core Duo 1.8 GHz so the problem is not that notorious.

At work I have an old workstation, Intel(R) Pentium(R) 4 CPU 2.80GHz so the slowness is more evident.  The problem is that this is a Fedora 11 system but the Firefox version is the same as Fedora 12 so I guess it's ok.  Do you want me to do more testing here? maybe a sysprof log with debugging packages?

Please remember to cross reference the upstream bug report with this one.

Comment 7 Matěj Cepl 2009-12-18 17:19:53 UTC
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

First of all, could we get output of the command

	rpm -qa \*xulrun\* \*firefox\* \*mozilla\* \*flash\* \*plugin\*

Please also install firefox-debuginfo (debuginfo-install is from
yum-utils package).

	debuginfo-install firefox

Please, install also valgrind (from valgrind package) and run

	valgrind --trace-children=yes \
		 --log-file=/tmp/firefox-valgrind-log.txt \
		 /usr/bin/firefox

(that's one line command, being broken into three lines notwithstanding)

Please, attach the file /tmp/firefox-valgrind-log.txt to this bug as an attachment as well.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 8 Matěj Cepl 2009-12-18 17:34:01 UTC
BTW, just to note ... this is just for a brief test ... if you think your Firefox was slow, let it run in valgrind, you will experience something !

Comment 9 William Lovaton 2009-12-24 18:17:50 UTC
Hello, sorry for the delay.  I'm really interesting in investigating and solving this issue.

First post...

# rpm -qa \*xulrun\* \*firefox\* \*mozilla\* \*flash\* \*plugin\*
xulrunner-1.9.1.6-1.fc12.i686
nspluginwrapper-1.3.0-10.fc12.i686
gedit-plugins-2.28.0-1.fc12.i686
abrt-plugin-bugzilla-1.0.0-1.fc12.i686
plymouth-plugin-label-0.8.0-0.2009.29.09.19.fc12.i686
gstreamer-plugins-ugly-0.10.13-1.fc12.i686
xulrunner-debuginfo-1.9.1.6-1.fc12.i686
abrt-plugin-sqlite3-1.0.0-1.fc12.i686
plymouth-plugin-two-step-0.8.0-0.2009.29.09.19.fc12.i686
anaconda-yum-plugins-1.0-5.fc12.noarch
gnumeric-plugins-extras-1.8.4-6.fc12.i686
gstreamer-plugins-bad-0.10.17-2.fc12.i686
gstreamer-plugins-base-0.10.25.1-2.fc12.i686
nspluginwrapper-debuginfo-1.3.0-10.fc12.i686
abrt-plugin-kerneloopsreporter-1.0.0-1.fc12.i686
firefox-3.5.6-1.fc12.i686
gdm-plugin-fingerprint-2.28.1-25.fc12.i686
mozilla-filesystem-1.9-5.fc12.i686
gstreamer-plugins-good-0.10.17-3.fc12.i686
firefox-debuginfo-3.5.6-1.fc12.i686
PackageKit-yum-plugin-0.5.4-0.4.20091029git.fc12.i686
gstreamer-plugins-flumpegdemux-0.10.15-8.fc12.i686
abrt-plugin-logger-1.0.0-1.fc12.i686
flash-plugin-10.0.42.34-release.i386
PackageKit-gstreamer-plugin-0.5.4-0.4.20091029git.fc12.i686
yum-plugin-fastestmirror-1.1.24-2.fc12.noarch
totem-mozplugin-2.28.4-1.fc12.i686
setroubleshoot-plugins-2.1.35-1.fc12.noarch
java-1.6.0-openjdk-plugin-1.6.0.0-33.b16.fc12.i686
alsa-plugins-pulseaudio-1.0.21-2.fc12.i686

Next post... the valgrind output.

Comment 10 William Lovaton 2009-12-25 06:46:19 UTC
Created attachment 380283 [details]
valgrind's output

This is the output of a firefox session under valgrind.  It was for about 10 minutes.

I have to say that the problem is a lot easier to trigger under valgrind even with a powerful CPU.  You can use top (refreshing every second) side by side with firefox and run the test attached to this bug report in comment #1.

If you let firefox idle it won't consume any CPU, but then if you try to click one checkbox over and over (I prefer to do it with the space bar) it will be responsive for a few seconds until it blocks with a high CPU consumption.  It then blocks for more than 20 seconds (in my case) until it gets responsive again.

You don't even have to click the checkbox over and over, you just have to click once and wait a few seconds for it to go high on the CPU, wait a lot of time for it to settle down and then click once again to see the same effect again.

I'm going to test if this has anything to do with the huge number of check boxes on the test page and report back.

Comment 11 William Lovaton 2009-12-25 07:29:00 UTC
Ok, I can confirm that this slowness is related to the number of form elements.  I made the same test with 1, 2 and 3 checkboxes and there is no high CPU consumption.  Just about 60% for about 1 or 2 seconds.

I then made the original test replacing all the check boxes for text boxes except for the first one.  Again, the slowness is reproducible, just clicking once on the checkbox fires up the CPU consumption to constant 100% for more than 20 seconds.

The problem is that my web application has some huge forms for a medical chart for pregnant women and there are a lot of form elements there.

Next test: check if this is reproducible on Windows, it's a shame there is no valgrind there.

Comment 12 Matěj Cepl 2009-12-27 23:54:10 UTC
We filed this bug in the upstream database (https://bugzilla.mozilla.org/show_bug.cgi?id=536910) and believe that it is more appropriate to let it be resolved upstream.

We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates.

Thank you for the bug report.

Comment 13 Matěj Cepl 2009-12-28 09:22:07 UTC
Reporter, could you please join the upstream bug, please, or should I answer instead of you?

"... does changing the "browser.sessionstore.privacy_level" preference to the
integer 2 make the problem go away?  This is sounding a lot like bug
https://bugzilla.mozilla.org/show_bug.cgi?id=477564 (certainly that's what the
testcase looks like).  But that claims to be fixed in 1.9.1.3, by capping to
100 elements.  Since you only have 100 elements, it might be that in your case
even doing 100 elements takes too long...."

Thank you very much


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