Closed
Bug 267179
Opened 20 years ago
Closed 17 years ago
nsReflowPath::EnsureSubtreeFor can be O(N) in the number of things needing reflow
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: bzbarsky, Unassigned)
References
Details
(Keywords: perf)
The walk along the mChildren array happens for every child of a given frame that we need to reflow, so the overall reflow tree construction can be O(N^2) for a very flat tree (eg several thousand abs pos divs that are all kids of the same thing being animated). Perhaps we should take the code in nsRuleNode that dynamically switches to a hashtable, factor it out into a separate class, and reuse it here? Or do we not care? For reference, nsReflowPath::EnsureSubtreeFor is about 1.5% of total time on the testcase in bug 229391.
Updated•20 years ago
|
Comment 1•17 years ago
|
||
Is this still relevant, since nsReflowPath no longer exists?
No, this code was removed in bug 300030. I suppose that means this is fixed, since the problem describe no longer exists...
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Depends on: reflow-refactor
Updated•6 years ago
|
Product: Core → Core Graveyard
Assignee | ||
Updated•6 years ago
|
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•