Performance bottleneck in PresShell::GetPrimaryFrameFor when scrolling the selection in long documents

NEW
Unassigned

Status

()

Core
Layout
8 years ago
8 years ago

People

(Reporter: Away for a while, Unassigned)

Tracking

({perf})

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
Steps to reproduce:

1. Load the log in the URL field (or any other tinderbox full build log).
2. Start a selection, and while holding down the mouse button, scroll towards the bottom of the document quickly.

In my Shark profile, 69.5% of the time was spent on PresShell::GetPrimaryFrameFor, and 25.8% of the time was spent on nsTextFrame::SetSelected.

The first one boils down to nsCSSFrameConstructor::FindFrameWithContent (which takes 61.5% of the processor time) and the second one to nsAttrAndChildArray::IndexOfChild (which takes 16% of the processor time).
I would imagine bug 500882 would help with the getting of primary frames part of this.
You need to log in before you can comment on or make changes to this bug.