Why are so many Array.prototype (iteration) methods so slow?

Question

I decided to assess all of my for loops in my project to see if I could replace it with an Array.prototype method - 75% of them could easily be replaced. Before I started the replacements, I thought I might run some tests. Most prototype methods were significantly slower (~80%) than polyfills on my machine.

Each of these tests are faster with a regular for loop

• Array.prototype.find vs. for loop
• Array.prototype.concat vs for loop
• Array.prototype.filter vs for loop
• Array.prorotype.forEach vs for loop
• Array.prototype.map vs for loop
• Array.prototype.reduce vs for loop
• Array.prototype.some vs for loop

I did not have the time to look up other jsperf tests, but i'm sure most prototype methods will be slower. So why? These functions are very useful, but how come they are so much slower than simple for loops.

Chrome 60.0.3112 / Windows 10 0.0.0

Answer 1

Unless js is parsed and we never know what the actual executed machine code looks like, its probably a good way of checking the efficiency of a high level algorithm to transpile it to assembly.

1) a regular for loop:

loop:
  CP A,100 //the exit statement
  JP z,end // exit

  LD A,123//some random math
  LD B,124
  ADD A,B
  LD 123,A

  JP loop //the actual loop     

end:

2) a prototype function:

Array_forEach:
loop:
  CP A,B //the exit statement
  JP z,end // exit

  LD 123,A//remove values from direct registers
  LD 124,B

  LD arg1,array_length //prepare function environment
  LD arg2,A

  CALL anonymous_func

  LD A,123
  LD B,124

  JP loop //the actual loop

anonymous_func:
  LD A,123//some random math
  LD B,124
  ADD A,B
  LD 123,A
  RET

As you can see, the forEach uses some expensive CALLs, not to mention the context change.

---

However, the parser may not even let both run that deep level, or it does some really good inlining, meaning that forEach actually runs faster than a for loop sometimes.