Comment by dahart | Hacker News Reader

Comment by dahart | Hacker News Reader

Parent Full thread

Check out gl-matrix.js, that’s one designed for being fast. It’s a simple math library, but the main way it achieves fast is by not allocating memory.

After having worked on JS for some large web apps that need good graphics performance, the two rules of thumb in my head for making JS fast are: 1- avoid dynamic memory allocation, and 2- avoid using the functional primitives like map.

The first one is more or less true in all languages, memory allocation always costs a lot, and if you can pre-allocate memory and/or re-use memory along the way, the code will run faster. This means paying attention to what things in JavaScript will allocate memory under the hood, use of dicts, use of 3rd party library and framework functions, etc.

The second one is a bummer; I love using the functional primitives. But map is slower than a for loop, all else being equal. It has gotten relatively faster over time. I mostly use functional everywhere, and only resort to for loops in performance critical code.

> 2- avoid using the functional primitives like map

I understand that map requires creating a new array, and that is already included in point 1. What overhead are functional primitives subject to apart from memory allocation? e.g. forEach

Using continuations. The function call itself and the local scope wrapped up into it can be varying degrees of expensive. When little state, because it’s inline or nearby for example, it might be optimized down to near what a for loop does. But if there’s a function call at all once it’s executed, that alone is slower than the for loop. Remember it’s a function call per element. If the function is further away with more scope, it can be more expensive both memory wise and time wise.

BTW, it's easy to test the basic primitives. I use Chrome snippets.

    test = (name, fn) => {
      const timeLimitMs = 1000
      let start = Date.now(), count = 0
      while (Date.now() - start < timeLimitMs) { fn(); count++ }
      console.log(name, count)  
    }
    var N = 1000000
    let a = new Array(N)
    test('for loop', _=> { for (var i = 0; i < N; i++) a[i] = i })
    test('map',      _=> { a = a.map((x,i) => i) })
    test('forEach',  _=> { a.forEach((v,i,a) => a[i] = i) })


    for loop 941
    map 37
    forEach 69

This is on my Mac in Chrome. So forEach is faster than map, but for loop is more than 10x faster than forEach. That's for loops with trivial work, of course. If the inside of the loop is expensive, the loop/map ratio will be lower.

If I modify that code to pre-initialise an array with the values 0 to N - 1, and then copy the value from that array to a new array (rather than using the loop index), then both map and forEach are faster than the for loop for me.

That sounds fairly surprising, considering map has to allocate, and allocate is very expensive, but please share your code & I’ll try it.

Like so?

    const N = 1000000
    let a = new Array(N), b = new Array(N)
    for (let i = 0; i < N; i++) a[i] = i
    test('copy loop',    _=> { for (var i = 0; i < N; i++) b[i] = a[i] })
    test('copy map',     _=> { b = a.map((x,i) => a[i]) })
    test('copy forEach', _=> { a.forEach((v,i,a) => b[i] = a[i]) })

I get: copy loop 973, copy map 38, copy forEach 49. Same as before, but this time I tried Chrome in Windows.

Are you using a different browser? I know that sometimes other browsers have very different results.

In any case, it's somewhat irrelevant if there are cases that optimize and cases that don't. When idiomatic functional code is sometimes up to 30x slower than a for loop, it can't be used in perf critical sections. Even if it's only Chrome and only certain cases. The forEach perf needs to be always reliably performant before I can use it without worry.

Thank you for the explanation

Reply on news.ycombinator.com