[CTW] Poor performance caching large text nodes
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox102 | --- | fixed |
People
(Reporter: Jamie, Assigned: Jamie, NeedInfo)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
STR:
- Enable CTW and restart Firefox.
- Open this test case:
data:text/html,<pre id="pre"></pre><script>let text = ""; for (let i = 0; i < 10000; ++i) { text += "this is a line of text\n"; } pre.textContent = text;</script>
- Expected: Content process blocks for several seconds.
- Actual: Content process should block for a fraction of a second.
This will happen whenever a user is loading large plain text files such as logs. I hit this myself loading a raw log from Treeherder.
Profile: https://share.firefox.dev/3vrAsBQ
This occurs when we're caching line start offsets. We spend a lot of time in nsTextFrame::GetRenderedText, which we use to convert between rendered and content offsets. I guess GetRenderedText has to do a linear walk, and because this text is so long, that is rather problematic.
It seems to me that the only kind of text node that is likely to be this long is pre-formatted text. In that case, the rendered offsets should be the same as the content offsets. Perhaps we can avoid calling GetRenderedText in this case. We should be able to detect that with frame->StyleText()->WhiteSpaceOrNewlineIsSignificant(), though we may need NewlineIsSignificant(frame) as well; I'm not sure.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
For pre-formatted text, the content text and rendered text are the same.
Therefore, there's no point calling nsIFrame::RenderedText, which is quite slow for nodes containing a large chunk of text.
This improves performance significantly when caching line start offsets for large plain text files such as logs.
Comment 3•2 years ago
|
||
Backed out for causing bustages at nsStyleStruct.h
Backout link: https://hg.mozilla.org/integration/autoland/rev/3d2770f4f06e8934e270bc142d40c5efd0947e1f
Push where failures started failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=Q30UVPn8Q9mHJofeSgBHLQ.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&searchStr=linux%2Cx64%2Cplain%2Cbuild-linux64-hybrid%2Fplain%2Cbp-hybrid&revision=b6daea0eb787ae4b418eb494e2d25f3b2444325c
Failure log: https://treeherder.mozilla.org/logviewer?job_id=376576809&repo=autoland&lineNumber=8933
Comment 5•2 years ago
|
||
bugherder |
Description
•