Hacker News Reader

Holy crap! I just had to check this and you are completely correct. map() is 10x slower in Chromium than overwriting an array. Interestingly, writing my own map operation in JS (by creating a new array and mutating it) was only 20% slower than mutating the original array. So something is very, very, very wrong with Array.map() on Chromium...

Then I checked it on Firefox. My hand-rolled map function is 3 times slower than the mutating version and the map() version is 1 or 2 orders of magnitude faster than the mutating version (as you would expect it to be).

So there is something wrong with Chromium, I think... Caveat: First thing in the morning on boxing day, back of the envelope style hacking. Having someone else verify my results would be nice ;-) Otherwise take it with a grain of salt...

Edit: The built in profiler was giving me strange results on Firefox, so I used the Gecko Profiler extension and it gave me something more reasonable: map() is about 50% slower than mutating the array and my handrolled map is about 20% slower than mutating the array. So that's a bit more consistent with Chromium's results.

Mind sharing the code you were testing this with? I have actually seen map perform better than for loops in Chrome in some cases (see https://www.measurethat.net/Benchmarks/Show/1096/0/map-vs-fo...).

It's very trivial (this is the bulk of it -- not showing everything to spare people from jumping over a huge message):

  var f = function f(num) {
    return num + 5;
  }

  var immutable = function immutable(arr) {
    return arr.map(f);
  }

  var mutating = function mutating(arr) {
    var i = 0;
    var l = arr.length;

    for(; i < l; i++) {
      arr[i] = f(arr[i]);
    }
    return arr;
  }

In my actual code, arr is a array of ascending numbers from 1 to 10,000 (different sized array each set of calls). I rebuild it before each call to immutable and mutating. I then run each of those functions, one after another 10,000 times. The intent is to make sure that there are no strange optimisations with a constant array and to even out the impact of the GC by interleaving the calls.

Unfortunately I tried to go to the link that you provided, but it just timed out :-(

Ah... it showed up. Hard to say what's going on there. I can't see the source code of how the benchmark works. But I do notice that you aren't returning the values. It is entirely possible that the code is being optimised out. I recommend returning the array. I also added up the elements of the array and checked that each implementation added up to the same number, just to make sure that the operation was actually performed.

Interesting. I did add a return to that benchmark and it didn't seem to affect the results. I would think your test would be identical to mine in performance characteristics, I wonder if it's just the benchmarking methods leading to the difference. I might just go write my own benchmarking like yours since I don't really know what measurethat.net is doing.

It seems intuitively obvious that map would be less efficient, but who knows what V8 is doing to optimize under the hood.

Given that they are so close in your example, I was thinking that it's possible that both sides are being optimised out, but that since the map side is smaller, it runs faster (i.e. the optimisation is at run time and so it still has to interpret the code -- smaller code interprets faster).

I haven't had time to revisit this since, but I think it's important. It is also possible that the profiling support in Chromium and Firefox is broken and I would very much like to know that if it is true.

Disclaimer: CS-Student who is interested in FP-languages but is yet not really experienced in this topic. I am also a bit drunk.

i think the problem is that js is not really designed for this kind of usage. If you look at this from the point pf view of an compiler FP is way easier to modify and optimize to improve performance. There are many factors but i believe the most important factor of future FP-base optimising compiler is rich type-info that makes many optimisation techniques possible or easier (this is important) to implement. While it's kinda boring, just look at haskell what possible there with rewrite rules. In a way it's possible to write your own compiler optimisation for your library.

In JS it's way harder because JS is untyped and the type system is way, way more complicated. Many of the hatches you use to optimise your program make it harder for the compiler to optimize your program. And i know about JIT-compiler, they are really complex beasts and the only way to tackle a language like JS. Just look (again) at Haskell, i always wondered what a really, really god JIT-compiler would look like. I would think that all the optimisation that you get by just using some pragmas would be only "engineering" work and don't require some fundamental breakthroughs. Especially if you consider the huge amount of time that went into something like the JVM.

> i always wondered what a really, really god JIT-compiler would look like.

Take a look at LuaJIT, then.

Also, I feel like it's worth mentioning that Haskell, OCaml, and Standard ML all have high-quality compilers available that can generate some pretty performant code. You won't get C speed out of them (at least not with idiomatic code), but you can wind up with executables that beat Java or C# perhaps, and easily beat the likes of Python, Ruby, Perl, JavaScript, ....

Take a look at asm.js. It's a subset of JS that uses de facto type annotations to let the JIT compiler get tremendous performance gains compared to normal JS - benchmarks put it at something like 1/2 the speed of raw C.

The problem, of course, is that (among other complications) you need to generate it from something that's completely strictly typed in order to do that in the first place, so most asm.js-compatble code is actually just generated anyway based on C or a similar language.

What about typing added on top of javascript for that purpose. Like typescript.

Typescript doesn't go far enough yet for asm.js code. It would need much more fine-grained types, like specific kinds of numbers instead of a single 'number' type.

I believe lots of people used FP to write short and correct programs; then they profile and tweak the bits that needs it.

Also, are you using javascript native .map method ? IIRC libraries like lodash or ramda, through use of reducers, have vastly faster idiomatic FP performance. Mostly because they avoid successive array allocation.

Sorry for being an idiot, but when you reducers you don't mean the native .reduce do you?

I'm not even sure it's reducers or transducers. It's mostly a type of functions, not the Array.reduce method. These function don't operate directly, they're meant to be recomposed later by the library. You can [].map(f).map(g).filter(h) and the system will "merge" f, g and h as a one step function that iterate once over the original data and without multiple array allocation. That's my partial understanding, there might be other subtleties.

I think you're talking about shortcut fusion.

What kind of applications are you building?