User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060106 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060106 Firefox/1.6a1 The deeper you are in a DOM tree structure, the worse Gecko performs (both on Mac OS X and Windows XP) when returning an offsetWidth or offsetHeight value after setting the style width and height on a parent DOM element. It appears that Safari 2.0 and Internet Explorer 6.0sp2 are able to compute these offsetWidth and offsetHeight values in relatively similar and very short amounts of time (e.g. 300 ms). The exact same test when run in Firefox (Deer Park 1.6a1 20060106) takes 3,000 ms--significantly worse performance. When profiling a Deer Park build we found that time was mostly spent processing reflows. I have been unable to find alternative ways of querying dimensions that perform any better than offsetWidth and offsetHeight. Reproducible: Always Steps to Reproduce: 1. Set up the DOM tree by having 200 levels of DIVs with 20 DIV dummy siblings at each level--this mimics DOM characteristics of a rich DHTML web application. 2. Get a timestamp. 3. Starting at the top of the tree of DIVs, get the offsetWidth and offsetHeight of the element's parent and then set the style width and height of the DIV to be, for simplicity, 0.98 times the parent's offset dimension values. (Do nothing with the dummy sibling DIVs). 4. Repeat step 3 all of the way down the DOM tree. 5. Get a new timestamp. Actual Results: The duration of the series of offsetWidth and offsetHeight queries and style dimension changes takes 3,000 ms on Firefox but only 300 ms on Internet Explorer 6.0sp2 and Safari 2.0. If using a profiler on a Deer Park build, we see most of the time is spent in the computation of the first offset dimension query after each style change. Expected Results: I expected Firefox to only take somewhere near 300 ms like the other browsers (e.g. +/- 50%) instead of 3,000 ms. I will attach the stand-alone HTML test case to reproduce the issue.
Created attachment 207723 [details] HTML Testcase to reproduce the performance issue noted in bug 322573
Component: General → DOM
Product: Firefox → Core
Version: unspecified → Trunk
Created attachment 207742 [details] Call graph of expensive code Attached a sample call graph of the expensive Gecko code found while profiling the issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed on OSX using official Firefox 1.5.1. My script uses offsetHeight and it renders much slower than in Safari or IE6. In Firefox it took 860ms, in Safari 20ms & in IE6 16ms.
Matt, the issue is that every time you ask for offset* values Gecko has to process all the pending style changes and perform relayout. This has gotten somewhat faster on trunk due to us optimizing away reflows better. I would be interested to know what results you see with a Firefox3 alpha build. Comparing to Safari, I'm not seeing anything close to a 10x time difference here.
added a quick comparison (see attachment) Firefox 13.0a1: 1159 ms Safari 5.1.2 : 233 ms Safari is approx 5 times faster as Firefox OS X 10.6.8 running on 2.66 GHz Core I7 MacBook Pro
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.