On Tue, Jul 30, 2013 at 6:52 PM, Jer Noble <jer.noble@apple.com> wrote: > > On Jul 30, 2013, at 8:47 AM, Jussi Kalliokoski < > jussi.kalliokoski@gmail.com> wrote: > > Does this impose a performance cost on Float32Array access, BTW? I tried > figuring it out on my own but I've been following leads in the WebKit > source for a while and haven't found the code that does this. > > > We re-used the high-order bit in ArrayBufferView's offset to track > non-neuterableness. So yes, in that offset calculations now need to mask > off that bit, but the cost is negligable. > > See: > http://trac.webkit.org/browser/trunk/Source/WTF/wtf/ArrayBufferView.h#L134 > http://trac.webkit.org/browser/trunk/Source/WTF/wtf/ArrayBuffer.cpp#L36 > Thanks! So, correct me if I'm wrong, but we're discussing imposing a performance cost (arguably negligible) to Typed Arrays use to avoid imposing a performance cost (arguably negligible) on the Web Audio API. To be honest, (probably unsurprisingly) I'd rather we take risks like this in our own API instead of on an API that's the foundation of high performance JS. We can add more surface to our API to make it faster if need be, but if we impose performance costs to the basic use of Typed Arrays, that's irreversible and damages the whole platform. Cheers, Jussi > -Jer >
Received on Tuesday, 30 July 2013 16:05:54 UTC