Open Bug 1189562 Opened 4 years ago Updated Last year
Web Audio CPU usage can climb during long waits for garbage collection
+++ This bug was initially created as a clone of Bug #974089 +++ Each Web Audio node (except Oscillator and AudioBufferSource) will consume cpu for as long as it lives. Some pages create many nodes and use them briefly before creating more similar nodes. I assume GC is tuned for memory pressure, not cpu resources. I think we need to stop depending on GC for cleaning up unnecessary streams. Bug 974089 addressed this for one-short source nodes. For others nodes, which can be reconnected, this may involve nodes recreating streams after they are destroyed. Another option might be to remove the stream from the graph and add later if required. This is a variation on bug 897796 comment 30: 1. Passive streams without input are destroyed. This includes streams with a node. 2. Newly connected source nodes will propagate (re)creation of streams for their output nodes. 3. Streams without node or output are destroyed. This includes active streams. 4. Occasional cycle collection on the graph collects cycles without nodes or outputs to nodes (sinks), and cycles without inputs from active streams. 1 and 2 can be implemented separately in this bug and 3 and 4 in bug 897796.
STR: 1. Load http://webaudiodemos.appspot.com/MIDIDrums/index.html 3. Wait for 10 or 20 seconds (for GCs to finish). 4. Click the play button with the triangle icon. 5. Observe CPU use of the audio thread ("threaded-ml" with PA) over a minute (If on a platform supporting "top", type 'H' for threads.) Desired results: CPU use remains consistent. Actual results: CPU use climbs for about a minute and then falls back and starts climbing again. Here, it may climb to close to 100% before falling back to 45%. Forcing CC from a preloaded about:memory in another window collects no objects and has no effect on cpu. Forcing GC causes CC to collect objects and the cpu usage falls.
Cc:ing :mccr8 so he can keep an eye on this from the CC/GC end of things.
The cpu usage of inactive nodes waiting for GC is now only a fraction of what it was when this bug was filed, but it can still become significant if nodes are created rapidly enough. Increasing Tempo to 180 BPM on http://webaudiodemos.appspot.com/MIDIDrums/index.html is one way to do this. The approach used for bug 1217625 et al differs from what was outlined in comment 0 in that streams are retained on inactive nodes but suspended. This avoids complications of passing state from AudioNode to AudioNodeEngine differently when there is no stream. There remain a few places where iterating over suspended streams should be skipped. Bug 1172997 covers the biggest CPU consumer. To avoid iterating over all suspended streams to check whether any have finished, I think it may be best to remove the main thread finished notifications code in PrepareUpdatesToMainThreadState() and instead add to mStreamUpdates or mUpdateRunnables more directly, perhaps via RunMessageAfterProcessing if required. This means that only streams that change state will be examined.
As Karl says in Comment 4, we've improved things a lot ("The cpu usage of inactive nodes waiting for GC is now only a fraction of what it was"). So I'm lowering the rank from 5 to 17. Karl -- IIUC you have other work that you need to do so I'm unassigning you as owner. Feel free to take this back if you have the time and plan to work on this
Assignee: karlt → nobody
Status: ASSIGNED → NEW
Rank: 5 → 17
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.