Project: v8 Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 2 users
Status: Duplicate
Merged: issue 2229
Owner: ----
Closed: May 2016
HW: ----
OS: ----
Priority: 2
Type: Bug



Sign in to add a comment
Array.forEach much slower than for() loop
Reported by stm...@gmail.com, May 25 2016 Back to list
Version: 229b66a5176e3d9b5bdf067fa53c6d4f3a00ce12
OS: OS X
Architecture: x86-64

The compilation of the following code snippets should result in identical performance, but does not:

slow:
```
    balls.forEach(function (ball) {
      if (ball.bounce()) {
        bounces += 1;
      }
    });
```

fast:
```
    for (var j = 0; j < balls.length; j++) {
      var ball = balls[j];
      if (ball.bounce()) {
        bounces += 1;
      }
    }
```


What steps will reproduce the problem?
1. out/native/d8 bounce-d8-slow.js
2. out/native/d8 bounce-d8-fast.js

Expected would be identical performance, but the slow version is about 3x slower.

This code is part of a benchmarking suite aimed at comparing languages, which
is developed here: https://github.com/smarr/are-we-fast-yet
At the moment, Node.JS/V8 show a huge outlier on this benchmark because of,
what I assume is a performance bug.

 
bounce-d8-fast.js
3.4 KB View Download
bounce-d8-slow.js
3.3 KB View Download
Mergedinto: 2229
Status: Duplicate
Why would you expect identical performance? the .forEach version does more work, function calls are relatively expensive (at least compared to "bounces += 1").
Comment 2 by stm...@gmail.com, May 25 2016
I would expect identical or close to identical performance here, because I'd expect that this gets all inlined.

To me it looks like the `forEach` and the lambda aren't inlined for some reason. Is this because of some heuristic not triggering, or is there something more fundamental going on here?

From the language semantics point of view, I wouldn't see any obvious reasons that should prevent it. Or am I missing something?

Thanks
Stefan
Well yes, a sufficiently smart compiler could inline it. Currently we don't. It's not as trivial as it may seem at first glance though. (Who's to say that the .bounce method doesn't fetch bounce.caller, the closure you expect to be eliminated.) The performance of .forEach will always be at least a little worse (requires more expensive warm-up), and will need more expensive tracking that a simple for-loop.
Project Member Comment 4 by bugdroid1@chromium.org, May 30 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/eff24bef5c0f071008bdd4bcee3a86384e90c90b

commit eff24bef5c0f071008bdd4bcee3a86384e90c90b
Author: cbruni <cbruni@chromium.org>
Date: Mon May 30 10:01:14 2016

[array] speed up array.forEach and friends by directly using in-operator

The in-operator has recently been optimized making our smart macros obsolete.
This should give up to 10% speedup on forEach and friends.

BUG= v8:5041 

Review-Url: https://codereview.chromium.org/2013873002
Cr-Commit-Position: refs/heads/master@{#36576}

[modify] https://crrev.com/eff24bef5c0f071008bdd4bcee3a86384e90c90b/src/js/array.js
[modify] https://crrev.com/eff24bef5c0f071008bdd4bcee3a86384e90c90b/src/js/macros.py

Labels: Priority-2
Sign in to add a comment