News for hackers. Stuff that matters.
Re:We rewrote our Rust WASM Parser in TypeScript – and it go... by asveikau on Friday March 20, 2026 @09:12PM (#47463010)
> After identifying the small misbehaving function, we had to study the C++ code pretty hard to even understand what the problem was. I don't remember the exact nature of the bug, but I do remember thinking that particular type of bug would be hard to express in Python, and that's exactly why it was accidentally fixed.

Pure speculation, but I would guess this has something to do with a copy constructor getting invoked in a place you wouldn't guess, that ends up in a critical path.

Re:We rewrote our Rust WASM Parser in TypeScript – and it go... by andrewflnr on Friday March 20, 2026 @10:01PM (#47463318)
Given the context, I'm thinking bad cache keys resulting in spurious cache misses, where the keys are built in some low-level way. Cache misses almost certainly have a bigger asymptotic impact than extra copies, unless that copy constructor is really heavy.
Re:We rewrote our Rust WASM Parser in TypeScript – and it go... by asveikau on Friday March 20, 2026 @10:07PM (#47463348)
I'm just remembering a performance issue I heard of eons ago where a sorting function comparison callback inadvertently allocated memory. It made sorting very slow. Someone said in a meeting that sorting was slow, and we all had a laugh about "shouldn't have used the bubble sort!" But it was the key comparison doing something stupid.
Re:We rewrote our Rust WASM Parser in TypeScript – and it go... by NooneAtAll3 on Friday March 20, 2026 @09:15PM (#47463039)
good ol' shallow-vs-deep copy
Re:We rewrote our Rust WASM Parser in TypeScript – and it go... by branko_d on Saturday March 21, 2026 @07:54AM (#47466211)
My guess would be bad hashing, resulting in too many collisions.