The stack overflow is caused by an `arr=[...]; events.push(...arr)` in `add_events`. Replacing that with `for(const x of [...]) events.push(x)` gets rid of that issue, and the JS-backed build is then snappier to search & filter than the WASM/Rust version.
I would imagine browsers optimize the iterator protocol away for arrays. At least on https://jsben.ch/iJFZ4 for..of is a smidge faster than an old-school loop.
You accidentally included the array initialization in the benchmarked code ("setup block" vs "boilerplate block"), dwarfing everything else. If we're talking about an already allocated array the difference is pretty big:
… but in a way you're correct that this is rarely the actual bottleneck in the surrounding code. Still, "death by a thousand papercuts" and all that. Plus having old-school for-loops as a habit makes it easier to spot the true botllenecks.
In your defense, the "use it for data initializing" suggestion isn't exactly helpful text either.
Also, for the record: I presume you tested on Chrome, but on Firefox the difference between the two loop styles is quite a bit larger (and generally slower than Chrome, so perhaps also a consideration when optimizing for "slowest browser" as the bottleneck).
Oh duh, yeah using spread syntax for function calls is definitely limited to fewer than 150,000 arguments in any browser that I know of. Don't expect everyone to know that, but I sure did, stupid that I didn't spot that. Thanks for pointing it out!
(funny enough I tend to use for(let i = 0; i < arr.length; i++) loops most of the time anyway because the iterator protocol adds too much overhead for my tastes, so I wasn't likely to ever bump into this in the first place)