On Wed, Jul 17, 2013 at 11:34 PM, Chris Rogers <crogers@google.com> wrote: > > > > On Wed, Jul 17, 2013 at 2:28 PM, Marcus Geelnard <mage@opera.com> wrote: > >> Just a few comments: >> >> 0) First, let me re-iterate that I think that it's unacceptable for us to >> move forward with a specification that allows for "shared mutable state >> without locks" (as Jens Nockert so concisely put it). I really think that >> we have to (and should be able to) find a solution to this. >> >> 1) memcpy is really, really fast on any modern CPU architecture (you'll >> find it's *the* most optimized routine, both in software and in hardware). >> Having hand optimized graphics rasterization loops in assembler for ARM >> I've learned that it's impossible to get even close to its speed even when >> only doing trivial stuff, such as adding a constant value to a buffer or so. >> > > Marcus, this isn't so much an issue of how fast memcpy() is, although that > could be a concern too. It's about the overhead of the additional memory > footprint (caused by the extra mallocs). > > Even so, I'm not convinced that it's a real-world problem. In most cases, I think that an application will simply upload audio data to an AudioBuffer, and be done with it (i.e. the source data is GC:ed), meaning no extra memory usage (except during a brief period during the copy operation). In some cases you would like to keep a JS side copy around (e.g. for an audio editor), but then I think we're talking about an application that would require quite much memory to begin with, and a factor 2x in RAM consumption is not uncommon in content editing software (i.e, I don't really see the problem). /Marcus
Received on Wednesday, 17 July 2013 21:43:41 UTC