Consider decode() with offset/length

[inexorabletash]

Context: https://bugs.chromium.org/p/chromium/issues/detail?id=1093980

When decoding a subset of an ArrayBuffer, the API currently requires the creation of a new view (Uint8Array) to encapsulate the byte offset/length. High performance applications try to avoid creating temporaries to reduce GC impact.

The request is to support a form of decode() which takes a buffersource, byte offset, and length. This could be done e.g. as:

decoder.decode(bufferSource, {offset, length});

(Although in real high-performance code the caller would re-use the options object.)

IIRC we talked about this in the distant past and decided "no, views are how you do this" but we now have developer feedback that this is a bottleneck. Improving the performance of bindings/GC is possible, but this API shape has a seemingly unnecessary overhead imposed by requiring views.

[annevk]

Yeah, see https://github.com/whatwg/encoding/issues/69#issuecomment-434539796 onward. https://github.com/whatwg/encoding/issues/69#issuecomment-434718429 mentions how you could optimize the view allocations away in Wasm (with theoretical host bindings).

1. Is the performance drawback consistent across browsers? How bad is it? (The bug doesn't go into much detail and it seems like a lot of effort to get access to the linked document.)
2. Has TC39 considered some kind of mutable view to help with these scenarios? It seems bad if we would have to do this for each API taking a view.
3. If we want speed is overloading the way to go? Dictionaries? (Why not use Wasm with theoretical host bindings?)

[hsivonen]

High performance applications try to avoid creating temporaries to reduce GC impact.

Is there a reason why the JS engines can't do escape analysis and heap-allocate temporary view objects? Is there a reason why the nursery in the GC doesn't take care of this?