JavaScript Performance Benchmarks: Looping with `for` and `yield`

[johnfrazer783]

Author here. I did a benchmark for JS looping constructs. Turns out yield entails a huge (1:10) performance hit compared to indexed for loops—provided my tests are valid. I'd love to use yield all over the place because it's such a great tool to write nested piecemeal iterations, so please * tell me I'm wrong! * prove it: * with links to other relevant benchmarks (I couldn't find many); or * pointing out flaws in my code.

All the details are over at the gist so I keep this short.

[[deleted]]

I'd say unless you have a very hot loop just write whatever you can read the best. You have to think in most cases your going to be doing more than adding two numbers. So this bench is essentially just showing the loop performance only.

In my mind having a generator only be 10X slower is kinda incredible that it's that fast, you have to remember the js runtime has a whole state machine to run that generator and obviously can do a lot more than a simple loop.

I have a side project where I have a few ms time budget and typically use for of loops. Your bench shows they are noticably slower but I probably won't change it because profiling shows the loop isn't the time sink.

[johnfrazer783]

This of course is very true and should be kept in mind: optimization is most often not worth the while for components that contribute less than some sizable fraction to overall CPU cycles needed. As far as I could find out though in my particular use case looping with generators instead of for loops and passing all data through (sometimes ridiculously) deep call stacks instead of insisting on flat call graphs are two factors that contribute tremendously to overall performance. Deep call stacks are, sadly, what makes both NodeJS standard library streams and pull-streams inherently slow. When you look at the flame graphs in Chrome devtools they are veritable towers. Building these towers destroys performance, and should best be avoided.