perf(web): optimize encodeInto()

[littledivy]

Towards #15895

• Use a preallocated Uint32Array result buffer. Much more efficient then serializing an object.

• Use v8::String::write_utf8 directly on the backing store.

• Use v8::ArrayBuffer::data instead of going through the backing store abstraction. See https://v8.github.io/api/head/classv8_1_1ArrayBuffer.html

  More efficient shortcut for GetBackingStore()->Data(). The returned pointer is valid as long as the ArrayBuffer is alive.

  Add v8::ArrayBuffer::Data rusty_v8#1068

5.4x faster encodeInto()

# This patch
target/release/deno run -A --unstable cli/bench/encode_into.js
time 78 ms rate 12820512
time 66 ms rate 15151515
time 65 ms rate 15384615
time 66 ms rate 15151515

# main
deno run -A --unstable cli/bench/encode_into.js
time 362 ms rate 2762430
time 340 ms rate 2941176
time 340 ms rate 2941176
time 339 ms rate 2949852

[ghost]

Would this same optimisation be applicable to encode() - the difference being who allocates the return Uint8Array?

[littledivy]

We are passing 100% of encodeInto WPT now! (SABs are allowed in the op now)

[bnoordhuis]

I still don't understand what guarantees alignment. Can you explain?

Note that getting the alignment wrong can lead to miscompiles, even on x86_64.

[ghost]

In JS, ArrayBuffers with a length ≥ the necessary alignment of type T, are usable as that type.

Upon second thought though, as this accepts TypedArrays and turns them into &mut [u8], then it's still unsound, as one may pass new Uint8Array(5).subarray(1), which has a byteOffset that isn't aligned to a u32 boundary.

[littledivy]

yikes, lemme add &mut [u32] support to #[ops] to directly deal with Uint32Array

[billywhizz]

i benchmarked this change against current implementation: #15895 (comment)

[bartlomieju]

Nice work!