Open
Bug 1214944
Opened 10 years ago
Updated 3 years ago
Get rid of mSpanFreeList of nsLineLayout and probably also mFrameFreeList?
Categories
(Core :: Layout: Block and Inline, defect)
Core
Layout: Block and Inline
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox44 | --- | affected |
People
(Reporter: xidorn, Unassigned)
Details
It seems to me in our current line layout code, it is very rare that we would use mSpanFreeList and mFrameFreeList, because nsLineLayout is always owned by the stack, and we create a new instance before reflowing every line, and we start freeing PSDs and PFDs almost only when we finish reflowing the line.
From the code coverage [1], the line
> outerLineLayout->mSpanFreeList = psd->mNextFreeSpan;
is never called in our tests, and the line
> outerLineLayout->mFrameFreeList = pfd->mNext;
have less than 0.01% hits comparing to the other branch which allcates a new one from the arena.
Given this, I think we can get rid of these two fields and always allocate the new instances from the arena.
Or probably we should make nsLineLayout live longer so that we may reuse them?
[1] https://www.tjhsst.edu/~jcranmer/m-ccov/layout/generic/nsLineLayout.cpp.html
Our tests are probably not a good example of data to use for performance measurement. Real Web pages would be better.
Reporter | ||
Comment 2•10 years ago
|
||
(In reply to David Baron [:dbaron] ⌚UTC-7 from comment #1)
> Our tests are probably not a good example of data to use for performance
> measurement. Real Web pages would be better.
It roughly matches my expectation (I expected that none of those lines are ever used, though).
All FreeFrame and FreeSpan calls are recursively from UnlinkFrame, and we call UnlinkFrame in EndLineReflow, PushFrame, and SplitLineTo. It seems to me after any of these calls, we are going to end the life of the line layout soon.
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•