[dead]
Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
31–40 of 136 posts
Re: Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
#32[dead]
Re: Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
#33[dead]
Re: Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
#34[dead]
Re: Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
#35[dead]
Re: Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
#36[dead]
Re: Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
#37[dead]
Re: Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
#38[dead]
Re: Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
#39[dead]
Re: Parquet-WASM: Rust-based WebAssembly bindings to read and write Parquet data
#40in my [albeit outdated] experience ArrowJS is quite a bit slower than using native JS types. i feel like crossing the WASM JS boundary is very expensive, especially for anything other than numbers/typed arrays. what are people's experiences with this?
Arrow JS is just ArrayBuffers underneath. You do want to amortize some operations to avoid unnecessary conversions. I.e. Arrow JS stores strings as UTF-8, but native JS strings are UTF-16 I believe.
Arrow is especially powerful across the WASM JS boundary! In fact, I wrote a library to interpret Arrow from Wasm memory into JS without any copies [0]. (Motivating blog post [1])
[0]: https://github.com/kylebarron/arrow-js-ffi
[1]: https://observablehq.com/@kylebarron/zero-copy-apache-arrow-...