Optimize the time marches on algorithm
Categories
(Core :: Audio/Video: Playback, task, P1)
Tracking
()
People
(Reporter: alwu, Assigned: alwu)
References
(Blocks 1 open bug)
Details
Attachments
(6 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
See bug 1974237, we have very worse performance while running time march on algorithm if a text track has huge amount of cues.
Assignee | ||
Comment 1•3 months ago
•
|
||
In bug 1974237 comment 2, running following script on this Dash player (VPN needed, not working for US)
(()=>{
const track = $('video')[0].textTracks[0]
const newMode = track.mode === 'showing' ? 'hidden' : 'showing'
const before = performance.now()
track.mode = newMode
const elapsedTime = performance.now() - before
const cues = track.cues?.length ?? 0;
console.log(`Setting text track mode to ${newMode} took ${elapsedTime}ms (${cues} cues)`);
})()
The result BEFORE optimization on my debug build is
Setting text track mode to showing took 69586ms (38780 cues) (original)
The result AFTER optimization on my debug build is
Setting text track mode to hidden took 175ms (38780 cues)
That shows the improvement around 397.63x faster. I will update my patches later after finishing testing.
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Comment 2•3 months ago
|
||
In TimeMarchesOn, we can replace TextTrackCueList with a nsTArray, which is a
more lightweight option.
Assignee | ||
Comment 3•3 months ago
|
||
Assignee | ||
Comment 4•3 months ago
|
||
Assignee | ||
Comment 5•3 months ago
|
||
Assignee | ||
Comment 6•3 months ago
|
||
Updated•3 months ago
|
Assignee | ||
Comment 7•3 months ago
|
||
Comment 8•3 months ago
|
||
(In reply to Alastor Wu [:alwu] from comment #1)
In bug 1974237 comment 2, running following script on this Dash player (VPN needed, not working for US)
(()=>{ const track = $('video')[0].textTracks[0] const newMode = track.mode === 'showing' ? 'hidden' : 'showing' const before = performance.now() track.mode = newMode const elapsedTime = performance.now() - before const cues = track.cues?.length ?? 0; console.log(`Setting text track mode to ${newMode} took ${elapsedTime}ms (${cues} cues)`); })()
The result BEFORE optimization on my debug build is
Setting text track mode to showing took 69586ms (38780 cues) (original)
The result AFTER optimization on my debug build is
Setting text track mode to hidden took 175ms (38780 cues)
That shows the improvement around 397.63x faster. I will update my patches later after finishing testing.
Very nice, can you compare with e.g. Chrome?
Comment 9•3 months ago
|
||
Also, if you have a minute, can you write in the commit message how much each patch contributes to the speed up? This is quite typical when working on performance, and helps to improve one intuition when working in optimizations in the future.
Assignee | ||
Comment 10•3 months ago
|
||
There’s still room for performance improvement, as Chrome runs the same script in under 5ms. I’ll continue optimizing this in Bug 1974237 and will update my commit message accordingly.
Comment 11•3 months ago
|
||
Assignee | ||
Comment 12•3 months ago
|
||
We can consider uplifting this improvement to ESR, once we can confirm that those patches don’t introduce any regressions.
Assignee | ||
Updated•3 months ago
|
Comment 13•3 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9ea8edcb9bb8
https://hg.mozilla.org/mozilla-central/rev/fabf5fe960ef
https://hg.mozilla.org/mozilla-central/rev/fadde6a5e612
https://hg.mozilla.org/mozilla-central/rev/e619d9f4d259
https://hg.mozilla.org/mozilla-central/rev/18f9a1592003
https://hg.mozilla.org/mozilla-central/rev/ac6d478c1fc9
Updated•2 months ago
|
Updated•2 months ago
|
Updated•1 month ago
|
Description
•