admin管理员组

文章数量:1244258

I have been discussing some code with colleagues:

for(const a of arr) {
  if(a.thing)
    continue;
  // do a thing
}

A suggestion was to filter this and use a forEach

arr.filter(a => !a.thing)
  .forEach(a => /* do a thing */);

There was a discussion about iterating more than necessary. I've looked this up, and I can't find anything. I also tried to figure out how to view the optimized output, but I don't know how to do that either.

I would expect that the filter and forEach turn into code that is very much like the for of with the continue, but I don't know how to be sure.

How can I find out? The only thing I've tried so far is google.

I have been discussing some code with colleagues:

for(const a of arr) {
  if(a.thing)
    continue;
  // do a thing
}

A suggestion was to filter this and use a forEach

arr.filter(a => !a.thing)
  .forEach(a => /* do a thing */);

There was a discussion about iterating more than necessary. I've looked this up, and I can't find anything. I also tried to figure out how to view the optimized output, but I don't know how to do that either.

I would expect that the filter and forEach turn into code that is very much like the for of with the continue, but I don't know how to be sure.

How can I find out? The only thing I've tried so far is google.

• javascript
• performance

Share Improve this question Follow edited Jan 2, 2019 at 16:43 loctrice asked Dec 31, 2018 at 19:38 loctriceloctrice 2,54311 gold badge2424 silver badges3535 bronze badges 9

• 1 The second snippet definitely loops twice, while the first one would loop only once. – Taplar Commented Dec 31, 2018 at 19:45
• 2 btw, the first approach is faster, even if you take a single forEach. – Nina Scholz Commented Dec 31, 2018 at 19:46
• 1 Good question! Just as a side note I would use for of instead of for in to iterate over an array. – kev Commented Dec 31, 2018 at 19:46
• 2 By the way, these two snippets are not functionally identical. filter predicates are written in the positive sense, in other words, filter will return entries which match, rather than discarding matches. So you should remove the !. – Brandon Commented Dec 31, 2018 at 21:28
• 2 @Brandon Actually, the ! is required in this case, since the action is supposed to happen if a.thing is falsy (the code hits continue when a.thing is truthy in the first example). The code was correct before. – Brian McCutchon Commented Dec 31, 2018 at 23:25

 |  Show 4 more ments

3 Answers 3

Sorted by: Reset to default 6

Your first example (the for in loop) is O(n), which will execute n times (n being the size of the array).

Your second example (the filter forEach) is O(n+m), which will execute n times in the filter (n being the size of the array), and then m times (m being the size of the resulting array after the filter takes place).

As such, the first example is faster. However, in this type of example without an exceedingly large sample set the difference is probably measured in microseconds or nanoseconds.

With regards to pilation optimization, that is essentially all memory access optimization. The major interpreters and engines will all analyze issues in code relating to function, variable, and property access such as how often and what the shape of the access graph looks like; and then, with all of that information, optimize their hidden structure to be more efficient for access. Essentially no optimization so far as loop replacement or process analysis is done on the code as it for the most part is optimized while it is running (if a specific part of code does start taking an excessively long time, it may have its code optimized).

When first executing the JavaScript code, V8 leverages full-codegen which directly translates the parsed JavaScript into machine code without any transformation. This allows it to start executing machine code very fast. Note that V8 does not use intermediate bytecode representation this way removing the need for an interpreter.

When your code has run for some time, the profiler thread has gathered enough data to tell which method should be optimized.

Next, Crankshaft optimizations begin in another thread. It translates the JavaScript abstract syntax tree to a high-level static single-assignment (SSA) representation called Hydrogen and tries to optimize that Hydrogen graph. Most optimizations are done at this level.
-https://blog.sessionstack./how-javascript-works-inside-the-v8-engine-5-tips-on-how-to-write-optimized-code-ac089e62b12e

^_*While continue may cause the execution to go to the next iteration, it still counts as an iteration of the loop.

The right answer is "it really doesn't matter". Some previously posted answer states that the second approach is O(n+m), but I beg to differ. The same exact "m" operations will also run in the first approach. In the worst case, even if you consider the second batch of operations as "m" (which doesn't really make much sense - we're talking about the same n elements given as input - that's not how plexity analysis works), in the worst case m==n and the plexity will be O(2n), which is just O(n) in the end anyway.

To directly answer your question, yes, the second approach will iterate over the collection twice while the first one will do it only once. But that probably won't make any difference to you. In cases like these, you probably want to improve readability over efficiency. How many items does your collection have? 10? 100? It's better to write code that will be easier to maintain over time than to strive for maximum efficiency all the time - because most of the time it just doesn't make any difference.

Moreover, iterating the same collection more than once doesn't mean your code runs slower. It's all about what's inside each loop. For instance:

for (const item of arr) {
  // do A
  // do B
}

Is virtually the same as:

for (const item of arr) {
  // do A
}
for (const item of arr) {
  // do B
}

The for loop itself doesn't add any significant overhead to the CPU. Although you would probably want to write a single loop anyway, if your code readability is improved when you do two loops, go ahead and do it.

---

Efficiency is about picking the right algorithm

If you really need to be efficient, you don't want to iterate through the whole collection, not even once. You want some smarter way to do it: either divide and conquer (O(log n)) or use hash maps (O(1)). A hash map a day keeps the inefficiency away :-)

---

Do things only once

Now, back to your example, if I find myself iterating over and over and doing the same operation every time, I'd just run the filtering operation only once, at the beginning:

// during initialization

const things = [];
const notThings = [];

for (const item of arr) {
    item.thing ? things.push(item) : notThings.push(item);
}

// now every time you need to iterate through the items...

for (const a of notThings) {  // replaced arr with notThings
    // if (a.thing)  // <- no need to check this anymore
    //    continue;

    // do a thing
}

And then you can freely iterate over notThings, knowing that unwanted items were already filtered out. Makes sense?

---

Criticism to "for of is faster than calling methods"

Some people like to state that for of will always be faster than calling forEach(). We just cannot say that. There are lots of Javascript interpreters out there and for each one there are different versions, each with its particular ways of optimizing things. To prove my point, I was able to make filter() + forEach() run faster than for of in Node.js v10 on macOS Mojave:

const COLLECTION_SIZE = 10000;
const RUNS = 10000;
const collection = Array.from(Array(COLLECTION_SIZE), (e, i) => i);

function forOf() {
    for (const item of collection) {
        if (item % 2 === 0) {
            continue;
        }
        // do something
    }
}

function filterForEach() {
    collection
        .filter(item => item % 2 === 0)
        .forEach(item => { /* do something */ });
}

const fns = [forOf, filterForEach];

function timed(fn) {
    if (!fn.times) fn.times = [];

    const i = fn.times.length;
    fn.times[i] = process.hrtime.bigint();
    fn();
    fn.times[i] = process.hrtime.bigint() - fn.times[i];
}

for (let r = 0; r < RUNS; r++) {
    for (const fn of fns) {
        timed(fn);
    }
}

for (const fn of fns) {
    const times = fn.times;
    times.sort((a, b) => a - b);
    const median = times[Math.floor(times.length / 2)];
    const name = fn.constructor.name;
    console.info(`${name}: ${median}`);
}

Times (in nanoseconds):

forOf: 81704
filterForEach: 32709

for of was consistently slower in all tests I ran, always around 50% slower. That's the main point of this answer: Do not rely on an interpreter's implementation details, because that can (and will) change over time. Unless you're developing for embedded or high-efficiency/low-latency systems -- where you need to be as close to the hardware as possible -- get to know your algorithm plexities first.

An easy way to see how many times each part of that statement is called would be to add log statements like so and run it in the Chrome console

var arr = [1,2,3,4];
arr.filter(a => {console.log("hit1") ;return a%2 != 0;})
   .forEach(a => {console.log("hit2")});

"Hit1" should print to the console 4 times regardless in this case. If it were to iterate too many times, we'd see "hit2" output 4 times, but after running this code it only outputs twice. So your assumption is partially correct, that the second time it iterates, it doesn't iterate over the whole set. However it does iterate over the whole set once in the .filter and then iterates again over the part of the set that matches the condition again in the .filter

Another good place to look is in the MDN developer docs here especially in the "Polyfill" section which outlines the exact equivalent algorithm and you can see that .filter() here returns the variable res, which is what .forEach would be performed upon.

So while it overall iterates over the set twice, in the .forEach section it only iterates over the part of the set that matches the .filter condition.

本文标签： javascriptDoes this for loop iterate multiple timesStack Overflow