[1]: https://github.com/nuejs/nue/blob/master/packages/examples/s...
Speaking of the code in question, it looks pretty sensible - there's a bit of low-hanging fruit where one could avoid creating redundant arrays by turning chained calls to map and filter into one for-loop and such, but that's about it.
What confuses me is that there's no point in the code where I see any recursion, here or in the other JS files that seem relevant, so how does one end up with a call stack overflow?
(not questioning that it crashed for you, it's just that I don't see any obvious flaws in the implementation, so I'm curious to lean what the "gotcha" is in case I ever bump into something like it myself)
(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)
… 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.
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).
Like, you're searching a single table for text messages, not a stream of events.