1926512 - Consider caching first-continuation/first-in-flow directly in nsSplittableFrame

Status: RESOLVED FIXED

(Core :: Layout, enhancement)

Description

[Jonathan Kew [:jfkthame]]

Bug 1865012 introduced first-in-flow/first-continuation caching in nsSplittableFrame using frame properties. However, in the pathologically-slow reflow seen in bug 1925916, profiling shows that the frame property access itself (nsIFrame::SetProperty and RemoveProperty) is a significant cost. It might be worth instead caching these pointers directly in member variables of nsSplittableFrame.

Looking at the first profile in bug 1925916, the long reflow is 4m 21s, and within this, there are 46.5K samples in nsIFrame::SetProperty/RemoveProperty -- essentially all of which are managing these nsSplittableFrame properties. That overhead will basically disappear if we move them into the frame itself.

In my local (non-PGO) build on Windows, making these member variables instead reduces the overall time for the example in bug 1925916 from 5 minutes to a bit over 3 minutes. Still far too long, of course, but it's a significant reduction.

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1926512 - Cache first-continuation/first-in-flow pointers directly in nsSplittableFrame. r=#layout

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/45ede4b715b4
Cache first-continuation/first-in-flow pointers directly in nsSplittableFrame. r=jwatt

Comment 3

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/45ede4b715b4