DASH processManifest performance regression in 3.x

[philippe-elsass-deltatre]

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
2.5.x, 3.x

Can you reproduce the issue with our latest release version?
Yes

Can you reproduce the issue with the latest code from main?
Didn't try

Are you using the demo app or your own custom app?
Custom

If custom app, can you reproduce the issue using our demo app?
N/A

What browser and OS are you using?
webOS, Tizen

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
webOS 5.00.35
Tizen firmware 2200.9

What are the manifest and license server URIs?

What configuration are you using? What is the output of player.getConfiguration()?

Default configuration

What did you do?

Play a live stream with large DVR (several hours) using different versions of Shaka Player on webOS and Tizen TV (low performance devices)

What did you expect to happen?
Playback should be smooth

What actually happened?

Using Shaka Player 2.5.x, Shaka is able to load and process the growing live manifest every few seconds.

Using Shaka Player 3.x, the processManifest step takes several seconds.

With a 4+h DVR, every time the manifest is reloaded:

• On Tizen, it takes close to 2s
• On webOS, it takes over 10s

There is visibly a considerable performance degradation of the manifest parsing logic, making it barely tolerable on Tizen (UI is frozen during the parsing), and completely unusable on webOS.

[philippe-elsass-deltatre]

I did some profiling and code reading and I strongly suspect a refactoring which happened between 2.5 and 3:

• Most of the for loops have been converted to enumeration loops
• Enumerations are using JS generators
• Generators seem to be transpiled to ES5...

Example in MpdUtils.js:

// Shaka 2.5.x
for (let i=0; i < timePoints.length; ++i) {

// Shaka 3.x
const enumerate = (it) => shaka.util.Iterables.enumerate(it);
for (const {item: timePoint, next} of enumerate(timePoints)) {

This looks like an absolutely catastrophic refactoring idea.

[avelad]

@joeyparrish / @theodab , can you check this? If so, I think it should be changed to improve performance.

[avelad]

I have created #4064 to fix these issues.

[philippe-elsass-deltatre]

Amazing @avelad - I was precisely doing these changes locally to see if it was fixing the issue :D

[avelad]

@philippe-elsass-deltatre Have you seen performance improvements with the fix?

[philippe-elsass-deltatre]

@avelad when profiling with Chrome browser there is a 10x improvement at least.

[philippe-elsass-deltatre]

However I'm seeing a worrying climbing of the memory

[avelad]

Have you seen any memory leak?

[philippe-elsass-deltatre]

There seem to be a massive memory leak: even after unloading Shaka I see memory climbing and if I pause JS I end up in a setTimeout callback looking at variants/codecs/decodingInfos

[avelad]

And is it caused by this change or is it reproduced in the master branch?

[philippe-elsass-deltatre]

I don't know that's odd - the player seem to be leaking if I build from source tag v3.3.2. Maybe I'm doing it wrong.

[philippe-elsass-deltatre]

Is there something faster than all.py to build the library? build.py doesn't seem to produce the shaka-compiled.js