"Because performance" doesn't seem a particularly good argument to choose one option over another. How fast a for, map, etc will run depends on more than its name, like optimisations that the runtime can do. So just choosr whichever fits your needs and if you run into performance issues profile and see what's causing the bottleneck (which probably won't be that map that you chose to use instead of a for loop).
Like this...
github.com/dg92/Performance-Analys...
Oh, you mean those tests in which if you place forEach before for then forEach becomes faster? The same tests in which if you actually use the result of the operation afterwards map becomes faster than for?
"Because performance" doesn't seem a particularly good argument to choose one option over another. How fast a
for
,map
, etc will run depends on more than its name, like optimisations that the runtime can do. So just choosr whichever fits your needs and if you run into performance issues profile and see what's causing the bottleneck (which probably won't be thatmap
that you chose to use instead of afor
loop).Yes! This is what I mean. Engineers should consider performance when deciding which method to use.