When viewing videos on a 4K firetv stick with geckoview, if the channel has a large number of watchers (likely really commenters), the video may stutter or more often eventually freeze as it streams all the comments by. When this happens, CPU use seems to be around 99% for long periods.

The guess is that all the comments are forcing lots of DOM manipulation and reflows/painting, and starving the media processing.

I'll capture gecko and simpleperf profiles on this case (Moto G5)

Simpleperf capture of twitch.tv running on the Moto G5 (all 79 threads). GeckoView_example 05/24/2019:
https://perfht.ml/2VUHWs7

It's running quite smooth even with the chat scroll.

Gecko Profiler capture on G5. Unfortunately missing many symbols even though this was from a taskcluster nightly build
https://perfht.ml/2VW6d0K

But I don't think the G5 is a good device to test this on since the top Fortnite channel ran very smoothly for me.

Andrew: can you check that the resolution is set high via the cog menu on Twitch and see if perf is still acceptable? Twitch should automatically switch to a lower quality resolution if the player is struggling to keep up with a higher resolution.

Chris: with the resolution set to the highest (1080p60, previously was auto) the top 4 streams on twitch.tv are all silky smooth on my Moto G5, even with busy chat channels.

(In reply to Andrew Creskey from comment #2)

Simpleperf capture of twitch.tv running on the Moto G5 (all 79 threads). GeckoView_example 05/24/2019:
https://perfht.ml/2VUHWs7

It's running quite smooth even with the chat scroll.

This is concerning: ~400ms locked up on the Socket Thread doing SSL decryption: https://perfht.ml/2I3bChU

Now, this may have been a big buffer of video data, perhaps - hard to tell. Still 400ms is a long time. (Actually from the interspersed ssl_DefRecv() -> recvfrom() samples, like it's a stream of packets arriving in a burst). If this code is sufficiently optimized, then it will take what it will take.

(I presume this is an Arm32 Android ABI-16 build)

jcj - thoughts?

Yes, this was an Arm32 android api 16 build.

We know NSS performance on 32-bit ARM is lackluster. In this case, it's AES-GCM, and that implementation is straight-C, without even NEON. In this case, we'd optimally want to prefer ChaCha20/Poly1305 -- which we're working on in Bug 1267894 (meta bug is bug 1555404).

That said, ChaCha20/Poly1305 isn't universally supported, and ultimately we want to have performant and safe algorithms everywhere.

Since this is fundamentally similar to our curve25519 on 32-bit ARM discussion in Bug 1550579, I've opened a meta bug about improving 32-bit ARM TLS performance, bug 1555407. We'll get started on research, but note that improving crypto takes time. (We don't even have 32-bit ARM build machines (https://treeherder.mozilla.org/#/jobs?repo=nss-try))

NI'ing Randell to see if things have improved after the NSS performance improvements.