3 ms·

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.ne

by Isobit 10y ago

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-for-loop https://www.measurethat.net/Benchmarks/Show/1096/0/map-vs-fo...).

mikekchar 10y ago
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.
- Isobit 10y ago
  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.
  - mikekchar 10y ago
    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.

by Isobit 10y ago

mikekchar 10y ago

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.

Isobit 10y ago
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.
- mikekchar 10y ago
  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.