Open Bug 1189562 Opened 4 years ago Updated Last year

Web Audio CPU usage can climb during long waits for garbage collection


(Core :: Web Audio, defect, P3)

26 Branch




(Reporter: karlt, Unassigned)


(Blocks 1 open bug, )


(Keywords: perf)

+++ 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.

1. Load
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.
Blocks: 1172181
Cc:ing :mccr8 so he can keep an eye on this from the CC/GC end of things.
Depends on: 1205540
Depends on: 1205558
Depends on: 1217625
Depends on: 1172997
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 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.
Depends on: 1274797
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
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 for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.