Open Bug 1296161 Opened 8 years ago Updated 2 years ago

Measure and solve sync reflow for studying gdoc performance.

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Project Flags:
Performance Impact low
Tracking Flags:
Tracking Status
firefox51 --- affected

People

(Reporter: sinker, Unassigned)

References

Details

(Keywords: perf) 

Bug 1260981 and it's blockers are studying the performances of google document.  We have found gdoc would measure dimensions, get clientWith, of text, or DIVs at the initialization stage.  And, I found Gecko would construct the whole frame tree and process all pending updates.

I don't look into details yet, but is it possible to contruct only frames and process only pending updates of ancestors and the content of the target element for clientWidth and clientHeight?
Not in general.  Layout algorithms have substantial dependencies between different parts of the tree.
Summary: get clientWidth on DIV would cause a heavy sync restyle/reflow. → Measure and solve sync reflow for studying gdoc performance.
I can see periods of 2xxms for getting |clientWidth| in JS script.  But, if I change as what I had mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1294625#c6 , they are gone.
No longer blocks: gdoc_read_basic_table_1_ubuntu(45.25%)
Whiteboard: [qf:p5]
Priority: -- → P3
Keywords: perf
Performance Impact: --- → P3
Whiteboard: [qf:p5]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.