User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 I visited http://www.ajuaonline.com/2007/10/02/how-to-remove-bonjour-service/ and noticed that on my Q9450 (4x 2.66ghz cores), Firefox 3.1 Beta 2 was using 100% of the CPU time on one of the cores. When I minimize the browser, it drops down to about 25%. Reproducible: Always Steps to Reproduce: 1. Visit http://www.ajuaonline.com/2007/10/02/how-to-remove-bonjour-service/ 2. Open Task Manager 3. Watch Firefox 3.1 Beta 2 use 100% of the CPU Actual Results: Firefox 3.1 Beta 2 uses 100% of the CPU. Expected Results: Should not be using 100% of the CPU.
every year the same... probably a dupe of bug 64516
Please do us all a favor and not mark performance bugs as duplicates unless you have a profile indicating that they really are, ok? Just because both scripts move things around doesn't mean they do it the same way, and especially with tracemonkey very tiny changes in the script can mean big (factor of 10 or more) differences in performance. Reopening.
See also bug 64516 comment 95
OK, so on Mac we spend something like 60% of the time painting (about 50-50 backgrounds and text, with some other bits tossed in). 20% of the time is spent actually running the JS and setting .style.left and .style.top. 5% of the time is restyles, and 3% is reflow. Of course on Windows things might look different... roc, do you think compositor would help here? As far as triage goes, what would help most here is a self-contained testcase attached to this bug.
Just an FYI, the latest version of Chrome also uses about 80-90% of 1 core while displaying this page. Latest version of IE7 uses about 15-20% of 1 core.
It's animating at 50 frames per second, which is fairly reasonable. So compositor probably wouldn't help here with the frame rate. Without some real debugging I can't tell if there are native widgets causing us to paint many times per frame.
Same behavior is seen with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081226 Shiretoko/3.1b3pre.
The layout debugger view/widget dump only shows two widgets... Is that reliable?
Here's another example (same script, newer version) that causes the problem: http://www.rajtilak.net/2009/01/finally-i-let-you-speak.html The script is actually located here: http://rajtilak.bhattacharjee.googlepages.com/snowstorm.js I'm using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Shiretoko/3.1b3pre.
My previous 2 links don't have the snowflakes on them anymore, but I did find a few more that are exhibiting the same problem with high CPU usage. http://www.hypergurl.com/snowmaker.html - When the tab is active, CPU usage is 100%. When the tab is not active, CPU usage is minimal. http://rainbow.arch.scriptmania.com/scripts/bg/snow_fall_1.html - This script only uses about 50%-75% of the CPU while active. http://www.schillmania.com/projects/snowstorm/ - uses 100% of the CPU while the tab is active.
See comment 3. Basically, each page that has a performance problem needs to be profiled separately and needs its own bug, unless there is data to indicate that they are the same issue...
The original URL in this bug is no longer a valid test for this. I filed a new bug for the 1st URL in comment 12. I'm just going to dupe this one against bug 529977.