Re: New proposal for fixing race conditions

Hi Russel,

I'm also a big fan of the ScriptProcessorNode (in fact, it's the one I use
the most), so I'm quite concerned with it's performance too.

On Saturday, July 20, 2013, Russell McClellan <russell@motu.com> wrote:
> I'm not sure I fully understand this new proposal by Jer, but it seems
like it requires a new allocation of an audio buffer every time a
ScriptProcessorNode processes an event.  If I'm right about this, my
intuition is that this will degrade the performance characteristics of the
ScriptProcessorNode.  I could be wrong about either of these propositions -
please correct me if I am.
>

Yes, but with Jussis proposal of adding an in-place get operation there's
no need for creating new objects. You'd still have to do two memcpy:s per
event for a signal processing script node (only one memcpy for a signal
generator). In general I don't think that it is a big performance hit (the
memcpy will likely be much cheaper than any JS processing going on in the
event handler), but this might be one use case that would benefit from
ownership transfer (i.e. neutering).

At this point I'm not all that concerned though. Any performance enhancing
API additions could be added later.

/Marcus

> This situation is sort of unfortunate from my perspective (i.e. a
potential user of the API), as we already have a thread-safe proposal on
the table that doesn't significantly degrade the performance of
ScriptProcessorNode (i.e., Robert's initial proposal).  As a user, I would
prefer as much performance as possible from the ScriptProcessorNodes.
>
> Thanks,
> -Russell
>