W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: New proposal for fixing race conditions

From: Jer Noble <jer.noble@apple.com>
Date: Fri, 19 Jul 2013 14:09:48 -0700
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, Robert O'Callahan <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>
Message-id: <9B8BC456-7E04-4983-8EEA-1A68E6E3A988@apple.com>
To: Marcus Geelnard <mage@opera.com>

On Jul 19, 2013, at 1:51 PM, Marcus Geelnard <mage@opera.com> wrote:

> On Fri, Jul 19, 2013 at 10:07 PM, Jer Noble <jer.noble@apple.com> wrote:
> 
> On Jul 19, 2013, at 12:52 PM, Marcus Geelnard <mage@opera.com> wrote:
> 
>> Also, I think it would be useful to have a more specific version of the set operation, in order to be able to update only a sub-part of the AudioBufferChannel from a sub-part of the source array (use case: editing & updating small parts of a large AudioBufferChannel). It would have to take two more arguments, e.g:
> 
> This is already achievable by creating a new Float32Array “view” onto the underlying ArrayBuffer.  I.e. to set ‘buffer' samples (50, 150] with only the first 100 samples from ‘array’:
> 
> 	buffer.set(array.subarray(0, 100), 50);
> 
> The TypedArray.subarray method involves no copying of the underlying data.
> 
> True, but I remember having problems with subarray this in the past. Specifically, it will increase GC activity since even though the subarray() method uses the same array memory, it still creates another ECMAScript object. Hard to say where to draw the line: subarray() is more elegant, but a more detailed set method would be (slightly) more efficient.

I can’t speak for other engines, but with JSC, GC activity scales with object size, not object count.  So small objects (even many small ones) are unlikely to significantly increase GC activity.

In 64-bit JSC, a Float32Array is 64 bytes.  It is 36 bytes in 32-bit.

-Jer
Received on Friday, 19 July 2013 21:10:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC