[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Typed Array setter for partial arrays (and typed array performance)

There's no large garbage:

function sliceFloat32Array(original, start, end) {
  var view = original.subarray(start, end);  // this allocates almost no memory. It's just a view
  return new Float32Array(view);  // this makes the same copy slice would have.

On Thu, Apr 28, 2011 at 5:22 PM, Ben Vanik <ben.vanik@gmail.com> wrote:
Extra garbage is scary - especially the large garbage likely created by doing that operation. Another nice thing about having a slice() is that it makes Typed Arrays more consistent with normal JS arrays, and eases the developer 'wth?' moments when discovering that for some reason slice() doesn't exist. If there were no slice() method in JS I'd say leave it out, but it seems better to create a consistent API across the whole web ecosystem.

Ben Vanik

On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell <kbr@google.com> wrote:
On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin <cmarrin@apple.com> wrote:
> On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote:
>> ...
>> As part of the planned Typed Array API changes to support efficient
>> communication with web workers, the plan is to add convenience methods
>> to copy ArrayBuffers and possibly sub-portions of them. I think we
>> should invest our time in moving those changes forward.
> Why is it necessary to have functions to copy ArrayBuffers. Isn't the copy constructor in the TypedArrays sufficient?

That's a fair point. During one of the face-to-face meetings with
Mozilla it seemed that if we used transfer-of-ownership for
ArrayBuffers sent via postMessage, then we had to make it easy to copy
them. You're right, though, that the slice() operation can be easily
implemented in pure _javascript_, with the only cost the creation of two
temporary Uint8Arrays.

Should we just get rid of it and provide non-normative text showing
how it could be implemented?