If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Unassigned

Status

()

Core
Web Audio
P2
normal
Rank:
17
2 years ago
12 days ago

People

(Reporter: karlt, Unassigned)

Tracking

(Blocks: 1 bug, {perf})

26 Branch
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

2 years ago
+++ 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.
(Reporter)

Comment 1

2 years ago
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.
Rank: 5
(Reporter)

Updated

2 years ago
Blocks: 1172181
Cc:ing :mccr8 so he can keep an eye on this from the CC/GC end of things.
(Reporter)

Updated

2 years ago
(Reporter)

Updated

2 years ago
Depends on: 1205540
(Reporter)

Updated

2 years ago
Depends on: 1205558
Comment hidden (obsolete)
(Reporter)

Updated

2 years ago
Depends on: 1217625
(Reporter)

Updated

2 years ago
Depends on: 1172997
(Reporter)

Comment 4

2 years ago
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.
(Reporter)

Updated

a year ago
Depends on: 1274797
Comment hidden (typo)
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
You need to log in before you can comment on or make changes to this bug.