1832377 - `layout`/GetClientBoundingRect is 3.5x slower then Chrome on Editor-TipTap and Editor-CodeMirror tests

Status: NEW

(Core :: Layout, enhancement)

Description

[Jeff Muizelaar [:jrmuizel]]

Eliminating the difference would gain us 19% on TipTap and 10% on CodeMirror

https://github.com/WebKit/Speedometer/blob/e1e156febb81facc2a2fe52ee4b0c8759d02a58e/resources/tentative/editors/tiptap.html#L167

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Do you happen to have a profile for this handy?

Comment 2

[Brian Grinstead [:bgrins]]

For a bit of context, the forced layout happens here at the end of each step https://github.com/WebKit/Speedometer/blob/e1e156febb81facc2a2fe52ee4b0c8759d02a58e/resources/tests.mjs#L342 inside each step. I wasn't am still am not positive if it should actually be added but it came over from the Monaco test in Grand Prix. There's also this line in the runner which should theoretically move the same work into async time but IIRC I tried to remove it at one point and ultimately didn't (perhaps it made the tests more noisy or removed work from the measured regions, I can't find notes).

Comment 3

[Jeff Muizelaar [:jrmuizel]]

FF: https://share.firefox.dev/44MEgNJ
Chrome: https://share.firefox.dev/3LLE6gU

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Sorry for the lag here. I think the reason why Chrome is not spending so much time during layout in getBoundingClientRect is that they update layout from Selection.anchorNode, for some reason, and that causes them to do more work afaict.

Taking that into account, do you know how much we spend in styling / layout comparatively on these tests? Given the above I don't think there's anything specific to getBoundingClientRect etc to look at.