My knowledge of assembly and machine language does indeed colour a lot of my choices, as well as my experience with how C compilers are some of the biggest shite out there given how often they don't optimize for dick often requiring multiple passes to do what a decent language can do in one.

I just don't expect an interpreter to do half the things a compiler does.

Unless they literally compile out the function--in which case those aren't object methods but language constructs -- the overhead of a function call for every iteration should be many many times slower because of the stack thrashing.

Though in JavaScript's case, a lot of times you can't measure it fully as far too much is left in place for garbage collection to handle later. One of the biggest mistakes I see in JS benchmarking -- and I've made this one myself -- is assuming that a .now() before and a .now() after will give you the actual execution time. Between things like render, garbage collection, async that we don't even know is async (that's sadly a thing in JS now) it's easy to delude oneself with the simple result.

That and the use of const for non-const assignment likely isn't helping matters.

Either way though, the way many developers lose their freaking minds when they see a "for" loop these days? It's really putting the herp in the derp given it's far less clear what you're doing, and the performance claims seem be almost entirely mythical.

-- EDIT -- OH! Big flub in yours. You're doing the same test in one file. Run each of them as separate files. Whichever one you run first typically runs fastest.

Which is sad since doing reduce first is 10ms slower here, which is below the 60ms reliable granularity of performance.now -- at least on my 5800x. Swap 'em around and the loop is 50ms faster... still under that 60ms margin of error.

Seriously, try swapping loop and reduce as to which runs first, and watch the numbers skew all over the place.

Also with the granularity issue, this is why I prefer to run a fixed time period and count how many can be done, instead of trying to track the actual execution time. No matter how many people cream their panties for "performance", it is NOT a reliable way to bench JS.