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

131–140 of 239 posts

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

#131

Post by necovek »

azakai wrote: post #28
nine_k wrote: post #5

"We rewrote this code from language L to language M , and the result is better!" No wonder: it was a chance to rectify everything that was tangled or crooked, avoid every known bad decision, and apply newly-invented better approaches. So this holds even for L = M . The speedup is not in the language, but in the rewriting and rethinking.

You're generally right - rewrites let you improve the code - but they do have an actual reason the new language was better: avoiding copies on the boundary. They say they measured that cost, and it was most of the runtime in the old version (though they don't give exact numbers). That cost does not exist at all in the new version, simply because of the language.

It's doing copies and (de)serialization on both sides into native data types.

If they used raw byte structures, implemented the caching improvements on the wasm side, the copies might not be as bad.

But they still have an issue with multi-language stack: complexity also has a cost.

Python/C combo does not have this issue because you can work with Python types natively in C, but otherwise, this is a cross-language conversion issue, and not a Rust issue at all.

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

#132

Post by zozbot234 »

bulbar wrote: post #124

Is this an outlier or has Rust started to be part of the establishment and being 'old' so that people want to share their "moving away from Rust" stories? I didn't mind reading articles that are not about how Rust is great in theory (and maybe practice).

This story is about moving away from WASM for an application that's unsuitable for it. It's not really about Rust.

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

#133

Post by johnisgood »

nine_k wrote: post #5

"We rewrote this code from language L to language M , and the result is better!" No wonder: it was a chance to rectify everything that was tangled or crooked, avoid every known bad decision, and apply newly-invented better approaches. So this holds even for L = M . The speedup is not in the language, but in the rewriting and rethinking.

I have been saying this for a while now (thought it was obvious), and often I get downvoted when I point this out.

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

#134

Post by johnisgood »

masklinn wrote: post #125
peter_retief wrote: post #123

Earlier quoted context omitted.

I suspect that you used highly optimized algorithms written for python, like the vector algorithms in numpy? You will struggle to write better code, at least I would.

Python 1.4 would be mid-late 90s long before numpy and vector algorithms would have been available. I suspect it’s more likely to be something like passing std::string by value not realising that would copy the string every time, especially with the statement that the mistake would be hard to express in Python.

Everything is new to the uninitiated. :P

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

#135

Post by elcritch »

eru wrote: post #130
rabisg wrote: post #103

Earlier quoted context omitted.

The last part is really interesting. It feels like the whole world will soon become Python/JS because thats what LLMs are good at. Very few people will then take the pain of optimizing it

The LLMs are pretty good at optimising. Not because they are brilliant, but because they are pretty good at throwing pretty much all known techniques at a problem. And they also don't tire of profiling and running experiments.

Not just profiling, but decoding protocols too.

Recently I tried Codex/GPT5 with updating a bluetooth library for batteries and it was able to start capturing bluetooth packets and comparing them with the libraries other models. It was indefatigable. I didn't even know if was so easy to capture BLE packets.

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

#136

Post by littlestymaar »

wiseowise wrote: post #113
ameixaseca wrote: post #86

Earlier quoted context omitted.

My experience is the exact opposite. This was particularly true for one of the projects I've worked with in the past, where Python was chosen as the main language for a monitoring service. In short, it proved itself to be a disaster: just the Python process collecting and parsing the metrics of all programs consumed 30-40% of the processing power of the lower end boxes. In the end, the project went ahead for a while…

> but in the end it was deemed a waste of time when the whole project was terminated. The main lesson of the story. Just pick Python and move fast, kids. It doesn’t matter how fast your software is if nobody uses it.

And this is why pretty much all commercial software is terrible and runs slower than the equivalent 20 years ago despite incredible advance in hardware.

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

#137

Post by tankenmate »

osullivj wrote: post #95
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.

Indeed a whole class of issues become moot if you just don't use javascript anywhere. In the browser world this is obviously difficult/impossible; I look forward to the day when WASM can run natively in a browser and doesn't need javascript at all, DOM, network, etc, etc. On the server side? Just steer clear of the javascript ecosystem altogether.

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

#138

Post by wolvesechoes »

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.

> The real win here isn't TS over Rust

Kinda is. We came up with abstractions to help reason about what really matters. The more you need to deal with auxillary stuff (allocations, lifetimes), more likely you will miss the big issue.

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

#139

Post by czhu12 »

ameixaseca wrote: post #86
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…

My experience is the exact opposite. This was particularly true for one of the projects I've worked with in the past, where Python was chosen as the main language for a monitoring service. In short, it proved itself to be a disaster: just the Python process collecting and parsing the metrics of all programs consumed 30-40% of the processing power of the lower end boxes. In the end, the project went ahead for a while…

Ditto for me. I had gotten so used to building web backends in Ruby and running at 700MB minimum. When I finally got around to writing a rust backend, it registered in the metrics as 0MB, so I thought for sure the application had crashed.

Turns out the metrics just rounded to the nearest 5MB

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

#140

Post by szmarczak »

kam wrote: post #38
szmarczak wrote: post #21

> Attempted Fix: Skip the JSON Round-Trip > We integrated serde-wasm-bindgen So you're reinventing JSON but binary? V8 JSON nowadays is highly optimized [1] and can process gigabytes per second [2], I doubt it is a bottleneck here. [1] https://v8.dev/blog/json-stringify [2] https://github.com/simdjson/simdjson

No, serde-wasm-bindgen implements the serde Serializer interface by calling into JS to directly construct the JS objects on the JS heap without an intermediate serialization/deserialization. You pay the cost of one or more FFI calls for every object though. https://docs.rs/serde-wasm-bindgen/

Indeed, you're right. However, it still needs to encode and decode strings. WASM just needs native interop.
Post reply on HN