2 ms·

You are making a strong evidence-free claim about what JS compilers don't do. https://stackoverflow.com/questions/9981607/array-foreach-running-faster-than-nat

• Teckla 2y ago
  At $WORK we use Mozilla Rhino for some JavaScript processing. We tested the normal loop vs. the clever loop. Performance-wise, the normal loop blew the doors off the clever loop.
  • MrJohz 2y ago
    Rhino is a very uncommon engine though. It has its niche, but if you're developing for simpler engines like that, then you typically know that in advance and know what considerations you're going to need to make for that. When it comes to performance, lessons that apply to Rhino are unlikely to apply to more mainstream engines. EDIT: That's not to say that everyone should use map and forEach all the time, just that your benchmarks are unlikely to be relevant to most JS devs outside of your specific use-case.
• jraph 2y ago
  You call "strong claim" something I prefixed with "probably"? It seems for loops in your link can be slower because .length (a function in disguise) is repeatedly called. I do save .length when writing JS. .length calls has been hard to optimize and it can't hurt too much to cache it at the start of the loop. Now it's good news if today's engines are able to optimize most of .forEach. The amount of optimization JS engines can do never ceases to amaze me and yes, any performance claim in JS needs to be constantly reviewed and checked at the time it is discussed. You can't take a "probably" as gospel. Still, it was a bit lazy of me to not re-check, I guess being called out was warranted.