Bug 518515
| Summary: | firefox horrible performance degrades user experience | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | William Lovaton <walovaton> | ||||||
| Component: | firefox | Assignee: | Gecko Maintainer <gecko-bugs-nobody> | ||||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 12 | CC: | gecko-bugs-nobody, mcepl | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-12-27 23:54:10 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
William Lovaton
2009-08-20 16:44:27 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.
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 Are you able to reproduce this with the upstream binary from www.mozilla.com? Yep, I downloaded the latest binary from mozilla.com and I can see the same problem there. 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). (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. 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. 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 ! 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. 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. 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. 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. 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 |