perf(web): optimize encodeInto() #15922
Conversation
|
Would this same optimisation be applicable to |
|
We are passing 100% of |
ext/web/lib.rs
Outdated
| // SAFETY: `out_buf` is guaranteed to be large enough to hold result. | ||
| let out_buf: &mut [u32] = unsafe { | ||
| std::slice::from_raw_parts_mut(out_buf.as_mut_ptr() as *mut u32, 2) | ||
| }; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
yikes, lemme add &mut [u32] support to #[ops] to directly deal with Uint32Array
|
i benchmarked this change against current implementation: #15895 (comment) |
| @@ -991,94 +991,8 @@ | |||
| "api-replacement-encodings.any.worker.html": true, | |||
| "api-surrogates-utf8.any.html": true, | |||
| "api-surrogates-utf8.any.worker.html": true, | |||
| "encodeInto.any.html": [ | |||
Towards #15895
Use a preallocated Uint32Array result buffer. Much more efficient then serializing an object.
Use
v8::String::write_utf8directly on the backing store.Use
v8::ArrayBuffer::datainstead of going through the backing store abstraction. See https://v8.github.io/api/head/classv8_1_1ArrayBuffer.htmlAdd
v8::ArrayBuffer::Datarusty_v8#10685.4x faster encodeInto()