Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We rewrote our Rust WASM parser in TypeScript and it got faster

openui.com

Post reply on HN
Print view View original

91–100 of 239 posts

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#91

Post by chvish »

joaohaas wrote: post #30

God I hate AI writing. That final summary benchmark means nothing. It mentions 'baseline' value for the 'Full-stream total' for the rust implementation, and then says the `serde-wasm-bindgen` is '+9-29% slower', but it never gives us the baseline value, because clearly the only benchmark it did against the Rust codebase was the per-call one. Then it mentions: "End result: 2.2-4.6x faster per call and 2.6-3.3x lower t…

This. It’s so annoying to read these types of blogs now where the writer clearly didn’t put the effort to understand things fully or atleast review the blog their LLM wrote. Who is this useful for?

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#92

Post by adastra22 »

blundergoat wrote: post #2

The real win here isn't TS over Rust, it's the O(N²) -> O(N) streaming fix via statement-level caching. That's a 3.3x improvement on its own, independent of language choice. The WASM boundary elimination is 2-4x, but the algorithmic fix is what actually matters for user-perceived latency during streaming. Title undersells the more interesting engineering imo.

No AI generated comments on HN please.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#93

Post by staticassertion »

jeremyjh wrote: post #51
rowanG077 wrote: post #27

Earlier quoted context omitted.

That's a pretty big claim. I don't doubt that a lot of uv's benefits are algo. But everything? Considering that running non IO-bound native code should be an order of magnitude faster than python.

Its a pretty well-supported claim. uv skips doing a number of things that generate file I/O. File I/O is far more costly than the difference in raw computation. pip can't drop those for compatibility reasons. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

Do you actually believe that UV would be as fast if it were written in Python?

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#94

Post by JimDabell »

joaohaas wrote: post #30

God I hate AI writing. That final summary benchmark means nothing. It mentions 'baseline' value for the 'Full-stream total' for the rust implementation, and then says the `serde-wasm-bindgen` is '+9-29% slower', but it never gives us the baseline value, because clearly the only benchmark it did against the Rust codebase was the per-call one. Then it mentions: "End result: 2.2-4.6x faster per call and 2.6-3.3x lower t…

The article as a whole makes no sense. They are generating UI with an LLM. How fast the UI appears to the user is going to be completely dictated by the speed of the LLM, not the speed of the serialisation.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#95

Post by osullivj »

simonbw wrote: post #74

Yeah if you're serializing and deserializing data across the JS-WASM boundary (or actually between web workers in general whether they're WASM or not) the data marshaling costs can add up. There is a way of sharing memory across the boundary though without any marshaling: TypedArrays and SharedArrayBuffers. TypedArrays let you transfer ownership of the underlying memory from one worker (or the main thread) to another…

Strongly agree from an Emscripten C++ wasm pov: it's key to minimise emscripten::val roundtrips. Caches must be designed for rectilinear data geometry, and SharedArrayBuffers are the way for bulk data. But only JS allows us to express asynchrony, so we need an on_completion callback design at the lang boundary.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#96

Post by staticassertion »

asa400 wrote: post #50
rented_mule wrote: post #34

Something not unlike this happened to me when moving some batch processing code from C++ to Python 1.4 (this was 1997). The batch started finishing about 10x faster. We refused to believe it at first and started looking to make sure the work was actually being done. It was. The port had been done in a weekend just to see if we could use Python in production. The C++ code had taken a few months to write. The port was…

Fun story! Performance is often highly unintuitive, and even counterintuitive (e.g. going from C++ to Python). Very much an art as well as a science. Crazy how many stories like this I’ve heard of how doing performance work helped people uncover bugs and/or hidden assumptions about their systems.

It doesn't come off as unintuitive by my read. They had a bug that led to a massive performance regression. Rewriting the code didn't have that bug so it led to a performance improvement.

They found that they had fewer bugs in Python so they continued with it.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#97

Post by athrowaway3z »

Its also worth underlining that it's not just "The parsing computation is fast enough that V8's JIT eliminates any Rust advantage", but specifically that this kind of straight-forward well-defined data structures and mutation, without any strange eval paths or global access is going to be JITed to near native speed relatively easily.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#100

Post by tda »

rented_mule wrote: post #34

Something not unlike this happened to me when moving some batch processing code from C++ to Python 1.4 (this was 1997). The batch started finishing about 10x faster. We refused to believe it at first and started looking to make sure the work was actually being done. It was. The port had been done in a weekend just to see if we could use Python in production. The C++ code had taken a few months to write. The port was…

Ome advantage of python is that it is so slow that if you choose the wrong algorithm or data structure that soon gets obvious. And for complicated stuff this is exactly where I find the LLMs struggle. So I make a first version in Python, and only when I am happy with the results and the speed feels reasonable compared to the problem complexity, I ask Claude Code to port the critical parts to Rust.
Post reply on HN