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)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: ehsan.akhgari, Unassigned)
References
()
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).
Comment 1•15 years ago
|
||
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.
Description
•