4 ms·

Speed isn't the only issue here. In fact, the execution of the looping construct itself is almost meaningless compared to what you're actually doing in it. (Exp

by inglor 13y ago

Speed isn't the only issue here. In fact, the execution of the looping construct itself is almost meaningless compared to what you're actually doing in it. (Explained here http://stackoverflow.com/a/17253577/1348195 http://stackoverflow.com/a/17253577/1348195 ) JSPerf is a horrible place to benchmark these things, see http://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html http://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.h... and http://mrale.ph/blog/2013/08/14/hidden-classes-vs-jsperf.html http://mrale.ph/blog/2013/08/14/hidden-classes-vs-jsperf.htm... by Vyacheslav Egorov (worked on v8) For example: if(array.length > 0) doFunction(array[0]); array.slice(1).forEach(doOtherFunction); Is far more readable and maintainable than that mess with the useless indexes and does the same thing. Optimizing based on microbenchmarks and not checking for deopts and doing profiling is worthless.

goldenkey 13y ago
It's not worthless when you are writing an app that happens to run in the browser. I agree 1000-fold that the Array manipulation techniques are extremely easy to read. Keep in mind though, you are creating a new copy of the [1-n]array through the slicing, and the overhead of the function call with forEach will matter on large Arrays. Really depends what you are building. Don't call performance optimization worthless.
- inglor 13y ago
  "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." - Knuth Micro benchmarks are not how we optimize - we profile.
- Eiwatah4 13y ago
  Who says the function call actually happens? If the function is short enough, they are a very good candidates for the JIT to inline. If they aren't short, the overhead of calling the function shouldn't matter much anymore.
mraleph 13y ago
While in general I indeed think that people should profile code before they optimize it, I also think that they should avoid unnecessarily pessimising it by writing code that is not exactly idiomatic and is known to have an overhead. In this particular case I am not sure I would prefer slicing+forEach to writing a old-style for-loop on any relatively hot path. Of course either profiling or thorough knowledge of the code should be applied before making this decision to determine whether this code path is hot or not, what's the average size of the array and so on. The main motivation for this decision would be the fact that slice produces the copy of the array. This is both hindrance in terms of performance (as VMs right now would not elide copy operation) and in terms of readability (e.g. when I see such code I would have to ask myself: does doOtherFunction require fresh copy or not, does it use only the first argument or all of what forEach passes into it and so on?). So you can see the choice for me is pretty complicated.

by inglor 13y ago

goldenkey 13y ago

It's not worthless when you are writing an app that happens to run in the browser. I agree 1000-fold that the Array manipulation techniques are extremely easy to read. Keep in mind though, you are creating a new copy of the [1-n]array through the slicing, and the overhead of the function call with forEach will matter on large Arrays. Really depends what you are building. Don't call performance optimization worthless.

inglor 13y ago
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." - Knuth Micro benchmarks are not how we optimize - we profile.
Eiwatah4 13y ago
Who says the function call actually happens? If the function is short enough, they are a very good candidates for the JIT to inline. If they aren't short, the overhead of calling the function shouldn't matter much anymore.

mraleph 13y ago

While in general I indeed think that people should profile code before they optimize it, I also think that they should avoid unnecessarily pessimising it by writing code that is not exactly idiomatic and is known to have an overhead. In this particular case I am not sure I would prefer slicing+forEach to writing a old-style for-loop on any relatively hot path. Of course either profiling or thorough knowledge of the code should be applied before making this decision to determine whether this code path is hot or not, what's the average size of the array and so on. The main motivation for this decision would be the fact that slice produces the copy of the array. This is both hindrance in terms of performance (as VMs right now would not elide copy operation) and in terms of readability (e.g. when I see such code I would have to ask myself: does doOtherFunction require fresh copy or not, does it use only the first argument or all of what forEach passes into it and so on?). So you can see the choice for me is pretty complicated.