1496096 - Horrible performance on runningworld due to media decoding

Status: NEW

(Core :: Audio/Video: Playback, defect, P3)

Description

[Randell Jesup [:jesup] (needinfo me)]

Loading this page (on any platform) pegs the CPU - 97% on a win10 mobile xeon P50 (dual gpu, Intel P530 + NVidia Quadro M2000M), 58% on a dual-XEON Linux desktop, and very bad on mac too (no % grabbed).

All the CPU time after load appears to be in media decoders (apparently ~25 of them) and related things; mainthread was 99% idle.

https://perfht.ml/2xZ2era (end of main load, lots of ION compiling happening you can't see)

perf profile at "idle": https://perfht.ml/2xRmc7l

Chrome appears to be using very little CPU on this on linux

Comment 1

[Michael Froman [:mjf]]

Jean-Yves,
Do you know who should take a look at this?

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Additional perf traces, including loading the page, showing massive contention on the memory lock:

https://perfht.ml/2y1jf45
ouch (though this is 35% of time not-waiting): https://perfht.ml/2xWgFw3
and https://perfht.ml/2xWgPUb

In addition to not software decoding/etc everything, there's quite a few issues shown in the traces

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

gecko profile with symbols.  This section shows ~29% lll_lock_wait; 6% directly in pthread_mutex_lock, 5% in lll_unlock_wake - and that's just mainthread

https://perfht.ml/2Qw2vce

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Attachment: debug patch to allow monitoring mutex contentionvia gdb - NOT FOR CHECKIN

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Mutex contention: Global allocator vs per-thread in MediaDecoders

Memory mutex contention in the content process, before (above) and after (below) switching to per-thread arenas for MediaDecoder's SharedThreadPool

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

For reference: this page has 25 videos (in firefox at least).  The smallest of them appears to be 1920x1238.  the larger ones are 3400x2266(!) @ 30fps.

This kills a machine when decoded with software.  Since we limit the number of simultaneous dxva-decoded videos to 8, this causes most (all?) to be software-decoded, even on win10 with a capable GPU (and thus crazy memory allocator traffic).  However, letting them all decode in HW is also horrible, just in different ways - profiles show it sitting in 

Note that Chrome does not appear to be actively decoding all these videos; they're all hidden.  When you click on the slideshow it unhides one of them at a time; this would match with they're all being HD or HD+.

Comment 7

[Andrew Creskey [:acreskey]]

I'm still seeing this issue on my MacBook Pro, 2017.

https://share.firefox.dev/3noQNlj

I do see a number of active media coder threads.

The scrolling performance in particular is noticeably better in Chrome and in Safari on the site.