"JS is really efficient if you replace most of its higher level native methods with bare-metal C analogues"
Yes, but this is arguably why WASM was invented.
It's the leveraging workers in parallel part that impresses me the most here because it's the most JS-like code in the thing.
It’s all about constraints … up to thousand rows, the common case, the initial implementation would be just fine; it’s scaling to 30x perf with even lower memory consumption that makes it a wonderful PL on demanding tasks that matters there, imho.
It seems like this approach could be leveraged in other PLs but JS's clear advantage is being sync by default so you don't need to write code to manage tasks running in parallel. Seeing oldschool `for…i++;` loops bothered me before remembering it's faster than `in` and ordered.
OTOH if that's genuinely the case, isn't that an argument for V8 looking at the code then selectively evaluating `for…in` internally as syntactic sugar for `for…i++;` instead of a separate method, or am I missing something obvious here? I am, aren't I.
`for in` has entirely different meaning, semantics, and implementation than `for i++` so I am not sure what you are after there ... maybe you meant `for of` which still uses generators, Symbol.iterator, and whatnot compared to `for i++` ??? 🤔
I remember taking a stab to it and just by passing some parameters to node the performance would improve because I realized that by default just reading the file was slow as hell as default chunks applied by node would make it super slow.
everything in there sounds reasonable and good to me ... node (as well as Bun) parameters can make some difference but I am sure it won't make a 30X improvement difference. Parameters are also "hard to share" as people would be 99% of the time on defaults but if you can tweak, tweak all the things 🥳
Comments
Yes, but this is arguably why WASM was invented.
It's the leveraging workers in parallel part that impresses me the most here because it's the most JS-like code in the thing.