Re: New proposal for fixing race conditions

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