Re: Proposal for fixing race conditions

> On Jul 16, 2013, at 6:43 PM, "K. Gadd" <kg@luminance.org> wrote:
> 
> I am literally unable to imagine a use case where the cost of the copies would add up to the point where it would remotely be considered a bottleneck.

Literally?

Keep in mind that it's not just the cost of memcopy, but also that of malloc.  After all, requiring memcopy implies there was some memory malloced to be the destination for the memcopy. In the worst case scenario\such as speccing that AudioBuffers always make a copy of all source data\this implies a doubling of required memory.

So how about a JavaScript-based Opus decoder that uses an AudioBuffer-backed ring buffer to do memcopy-free decoding and playback by decoding directly into a mutable AudioBuffer. If AudioBuffer.getAudioData() suddenly causes a memcopy, (or in an immutable world, the AudioBuffer must be recreated) suddenly the ring buffer memory use doubles. On an embedded system with no page file, this causes the UA to hit a hard memory limit (and be killed as a result) more often.

Or, the constant mallocing of small buffers (as the existing ones are either neutered or immutable) causes GC to activate more often (where it never did before) causing GC-related hiccups.

The possibilities for performance regressions are extensive. 

> It is the case that the copies probably have to be synchronous, so I could see this hurting the ability to trigger tons and tons of sounds in a single 'frame' from JS, or set tons and tons of curves, etc. But still, memcpy isn't that slow, especially for small numbers of bytes.

As Chris (Rogers) has repeatedly pointed out, decoded audio data is not a small number of bytes. 1 second of 32-bit, 44kHz,  stereo audio data is over 300kB. A 5 minute song will decode to over 100MB.

It's bad enough that naive authors will decode all of a 5 minute audio file at once, causing huge up front memory usage. Doubling that would be disastrous.

-Jer

Received on Wednesday, 17 July 2013 06:06:37 UTC