Consider coalescing nested nsInlineFrame instances, for deeply-nested subtrees of unstyled display:inline elements
Categories
(Core :: Layout: Block and Inline, enhancement)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf:pageload)
Bug 216418 has some pathological testcases with extremely many inline wrapper frames, which we spin our wheels allocating, reflowing, and fragmenting. These are all unstyled, so (given that they're wrapping the same content) they all have the same bounds, fragmentation boundaries, etc. If we're careful, we could probably get away with just using one shared nsInlineFrame for the whole stack of elements, or something to that effect.
It looks like Chrome is doing something along those lines -- they appear to be doing some sort of optimization to coalesce or ignore all of these inline wrappers. At least: comparing these two testcase in Chrome...
https://bugzilla.mozilla.org/attachment.cgi?id=9333233
https://bugzilla.mozilla.org/attachment.cgi?id=9333234
...shows a substantial performance difference (10-50ms for the first vs. 700-1500ms for the second), though the only difference in the markup is that there's a non-functional margin-top styling on the inline elements in the second testcase, which I imagine is defeating Chrome's optimization.
We may want to consider implementing a similar optimization so that we can achieve similar trivial rendering times for the first testcase here. The original real-world testcase on bug 216418 has a whole bunch of accidental levels of inline-element nesting, with unstyled inline-level wrapper elements, due to having a bunch of stuff like From <foo@example.com> in the source. Each <foo@example.com> expression is interpreted as an unrecognized HTML element, and adds a level of nesting.
Description
•