Closed Bug 1832678 Opened 2 years ago Closed 2 years ago

Avoid InitCBReflowInput's call to nsIFrame::GetContainingBlock, if our parent frame could not possibly be a containing block

Categories

(Core :: Layout: Block and Inline, defect)

defect

Tracking

()

RESOLVED FIXED
115 Branch
Tracking Status
firefox115 --- fixed

People

(Reporter: dholbert, Assigned: tnikkel)

References

(Blocks 1 open bug)

Details

(Keywords: perf:pageload)

Attachments

(2 files)

In the profile links in bug 216418 , we spend a lot of time in ReflowInput::InitCBReflowInput()'s call to GetContainingBlock (and probably that time is mostly spent walking the ancestor frame tree to discover the nearest block which is quite far away due to how many layers of inline-level elements the content is wrapped in).

This call is almost entirely unnecessary in that case; we only use the return value for the purpose of checking if it matches our parent frame. In this case, our parent frame is almost always an inline-level frame, so it can't match.

We should optimize that call away by first checking whether our parent frame could possibly be something that GetContainingBlock could return (e.g. if it's block-level).

Blocks: 216418

See more notes in bug 216418 comment 45, section (1), too.

Assignee: nobody → tnikkel
Status: NEW → ASSIGNED

testcase 2 from bug 216418
trunk about 2900ms
with bug 1832685 about 2400ms
with bug 1832685 and the patch in this bug about 1900ms.

Pushed by tnikkel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e22a29df339c Factor out an nsIFrame::IsBlockContainer helper. r=dholbert https://hg.mozilla.org/integration/autoland/rev/2fbe220a08cf Avoid InitCBReflowInput's call to nsIFrame::GetContainingBlock, if our parent frame could not possibly be a containing block. r=emilio
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 115 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: