See bug 1974237, we have very worse performance while running time march on algorithm if a text track has huge amount of cues.

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.

In TimeMarchesOn, we can replace TextTrackCueList with a nsTArray, which is a
more lightweight option.

(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?

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.

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.

We can consider uplifting this improvement to ESR, once we can confirm that those patches don’t introduce any regressions.

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