322573 - poor performance in calculating offsetWidth or offsetHeight after setting a style width or height

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Matt Cooper]

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.

Comment 1

[Matt Cooper]

Attachment: HTML Testcase to reproduce the performance issue noted in bug 322573

Comment 2

[Matt Cooper]

Attachment: Call graph of expensive code

Attached a sample call graph of the expensive Gecko code found while profiling the issue.

Comment 3

[yoav]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Attila Soki]

Attachment: Comparison Firefox vs Safari

Comment 6

[Attila Soki]

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

Comment 7

[Firefox Bug Husbandry Bot]

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.