Closed Bug 529096 Opened 15 years ago Closed 2 years ago

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

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: ehsan.akhgari, Unassigned)

References

(
URL
)

Details

(Keywords: perf) 

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.

Page no longer active

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.