Consider to use medium high priority queue for speculative load runnable
Categories
(Core :: DOM: HTML Parser, defect, P2)
Tracking
()
People
(Reporter: smaug, Assigned: smaug)
Details
Attachments
(1 file)
We should probably try to flush speculative loads asap.
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
Assignee | ||
Comment 3•5 years ago
|
||
Assignee | ||
Comment 4•5 years ago
|
||
Updated•2 years ago
|
Comment 5•10 months ago
|
||
I'm wondering what would be the best way to evaluate this.
In our CI tests we connect via https proxy which disables speculative connection in some codepaths.
And there's no latency in that environment, so we may not see the impact.
Maybe a local browsertime run with network throttling could at least give us a clue as whether or not this is worth pursuing.
Comment 6•10 months ago
|
||
Oh, I think the work here was already done in bug 1800381 as we now send this with RenderBlocking priority:
https://searchfox.org/mozilla-central/rev/00e348d6935d99a089c318f4512b22327c22154b/parser/html/nsHtml5StreamParser.cpp#1817-1819
Comment 7•10 months ago
|
||
Before I realized that we had already increased the priority of the runnable, I added a temporary PerfStat to see if we could measure an improvement in the delay it takes the Htm5SpeculativeLoad runnable to executre.
And in fact if I rollback the change from Bug 1800381 as the baseline and compare against the current, we see a whole bunch high-confidence improvements in that PerfStat:
Smaug: I think we can close this as dupe of bug 1800381 unless you can think of anything else to do here?
Assignee | ||
Comment 8•10 months ago
|
||
Ah, this does look like a dup. There might be still some more tweaks to do, but we can file followups.
Updated•10 months ago
|
Description
•