Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

buffer: Reverting change in let to fix regressions in buffer operations #5819

Closed
wants to merge 1 commit into from
Closed

buffer: Reverting change in let to fix regressions in buffer operations #5819

wants to merge 1 commit into from

Conversation

gareth-ellis
Copy link
Member

Pull Request check-list

Please make sure to review and check all of these items:

  • Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with
    this change (including linting)?
  • Is the commit message formatted according to CONTRIBUTING.md?
  • If this change fixes a bug (or a performance problem), is a regression
    test (or a benchmark) included?
  • Is a documentation update included (if this change modifies
    existing APIs, or introduces new ones)?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.

Affected core subsystem(s)

buffer

Description of change

Using let in for loops showed a regression in 4.4.0. @ofrobots suggested
that we avoid using let in for loops until TurboFan becomes the default
optimiser.

As discussed in nodejs/benchmarking#38

@gareth-ellis gareth-ellis changed the title buffer: changing let in for loops back to var buffer: Reverting change in let to fix regressions in buffer operations Mar 21, 2016
@mscdex mscdex added the buffer Issues and PRs related to the buffer subsystem. label Mar 21, 2016
@@ -292,7 +292,7 @@ Buffer.concat = function(list, length) {

var buffer = Buffer.allocUnsafe(length);
var pos = 0;
for (let i = 0; i < list.length; i++) {
for (i = 0; i < list.length; i++) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wondering why no var here. Looks like it was there previously 2ac47f8. At this point since its a jslint error all I can think of is that we have tightened up the lint rules ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this was to address a lint issue.

Really the var i in the for loop before should be declared outside of the if statement, so have added another commit to fix this,

@Fishrock123
Copy link
Contributor

@Fishrock123 Fishrock123 added the v8 engine Issues and PRs related to the V8 dependency. label Mar 21, 2016
@trevnorris
Copy link
Contributor

Can you include specific information about the regression in the commit message? I'm not sure if this is testable, but in the future when a developer wants to reintroduce let it will be helpful to clearly understand why this was reverted.

Also include a Ref: to the benchmarking issue referenced in the OP.

Code change LGTM.

@jasnell
Copy link
Member

jasnell commented Mar 21, 2016

LGTM (with @trevnorris' nits addressed)

@mhdawson
Copy link
Member

Lgtm

@MylesBorins
Copy link
Contributor

nit: The two commits should be squash, and the commit message should be wrapped to 72 characters (currently the first lint in the comment is 73)

otherwise LGTM

Using let in for loops showed a regression in 4.4.0. @ofrobots
suggested that we avoid using let in for loops until TurboFan becomes
the default optimiser.

The regression that was detected was when looking at how long it took
to create a new buffer from an array of data.

When using `for (let i=0; i<length; i++) ` we saw the operation take
almost 40% longer compared to `var i=0`.

Ref: http://github.com/nodejs/benchmarking/issues/38
@gareth-ellis
Copy link
Member Author

Have squashed the commits and expanded commit message.

@MylesBorins
Copy link
Contributor

👍

@trevnorris
Copy link
Contributor

excellent thanks

@mscdex
Copy link
Contributor

mscdex commented Mar 21, 2016

Isn't it let usage in general and not just loops? There's a let in .toString() that could easily change to var.

@MylesBorins
Copy link
Contributor

@mscdex perhaps we should open another issue regarding no longer using let in the code base... there are quite a few lets (including others in for loops).

The biggest push back I saw what that it is a micro optimization for non-hot code

Thoughts?

@gareth-ellis
Copy link
Member Author

I just did a quick test, similar to the benchmark I ran originally, but this time looking at .toString

I got two builds, one with var result; and the second with let result;

first of all, with let
*let_tostring/Release/node to-string-test/to-string-test.js *
total time: 5.008s -- iterations: 199 -- ops/sec: 39.74 -- average time: 0.03s -- variance: 2.18%
total time: 5.018s -- iterations: 202 -- ops/sec: 40.26 -- average time: 0.02s -- variance: 1.47%
total time: 5.012s -- iterations: 201 -- ops/sec: 40.1 -- average time: 0.02s -- variance: 1.5%
total time: 5.016s -- iterations: 202 -- ops/sec: 40.27 -- average time: 0.02s -- variance: 1.51%
total time: 5.001s -- iterations: 202 -- ops/sec: 40.39 -- average time: 0.02s -- variance: 1.87%
total time: 5.012s -- iterations: 203 -- ops/sec: 40.5 -- average time: 0.02s -- variance: 1.88%
total time: 5.012s -- iterations: 203 -- ops/sec: 40.5 -- average time: 0.02s -- variance: 1.88%

*var_tostring/Release/node to-string-test/to-string-test.js *
total time: 5.024s -- iterations: 197 -- ops/sec: 39.21 -- average time: 0.03s -- variance: 2.26%
total time: 5.006s -- iterations: 200 -- ops/sec: 39.95 -- average time: 0.03s -- variance: 0.89%
total time: 5.016s -- iterations: 201 -- ops/sec: 40.07 -- average time: 0.02s -- variance: 1.22%
total time: 5s -- iterations: 201 -- ops/sec: 40.2 -- average time: 0.02s -- variance: 1.33%
total time: 5.007s -- iterations: 202 -- ops/sec: 40.34 -- average time: 0.02s -- variance: 1.8%
total time: 5.015s -- iterations: 203 -- ops/sec: 40.48 -- average time: 0.02s -- variance: 1.85%
total time: 5.015s -- iterations: 203 -- ops/sec: 40.48 -- average time: 0.02s -- variance: 1.89%

The amount the results are bouncing around, I'd suggest that the two are performing the same.

My benchmark, was measuring how many operations /second I could get when repeating this:

var TEXT = "Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.";
var ITERATIONS = 200000;
var buffer = new Buffer(TEXT, 'utf-8');
var stringFromBuffer;

function test() {
        for(var i=0;i<ITERATIONS;i++) {
                stringFromBuffer = buffer.toString();
        }
}

harness.run_test(test);

@benjamingr
Copy link
Member

@mhdawson
Copy link
Member

ok looks like we have a number of lgtm. @benjamingr you planning to land ? If not I can look at doing it later today

@benjamingr
Copy link
Member

Sure, I'll land.

benjamingr pushed a commit that referenced this pull request Mar 23, 2016
Using let in for loops showed a regression in 4.4.0. @ofrobots
suggested that we avoid using let in for loops until TurboFan becomes
the default optimiser.

The regression that was detected was when looking at how long it took
to create a new buffer from an array of data.

When using `for (let i=0; i<length; i++) ` we saw the operation take
almost 40% longer compared to `var i=0`.

PR-URL: #5819
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Trevor Norris <trevnorris@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Ref: http://github.com/nodejs/benchmarking/issues/38
@benjamingr
Copy link
Member

Landed in 443c2d5 , thanks!

@jasnell jasnell closed this Mar 23, 2016
evanlucas pushed a commit that referenced this pull request Mar 30, 2016
Using let in for loops showed a regression in 4.4.0. @ofrobots
suggested that we avoid using let in for loops until TurboFan becomes
the default optimiser.

The regression that was detected was when looking at how long it took
to create a new buffer from an array of data.

When using `for (let i=0; i<length; i++) ` we saw the operation take
almost 40% longer compared to `var i=0`.

PR-URL: #5819
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Trevor Norris <trevnorris@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Ref: http://github.com/nodejs/benchmarking/issues/38
@MylesBorins
Copy link
Contributor

@nodejs/lts we usually wait for things to spend time on v5 before backporting. This change is unlikely to cause breakage, and will result in immediate performance improvements. Are people opposed to having this land in this weeks release?

@jasnell
Copy link
Member

jasnell commented Mar 30, 2016

No objections

MylesBorins pushed a commit that referenced this pull request Mar 30, 2016
Using let in for loops showed a regression in 4.4.0. @ofrobots
suggested that we avoid using let in for loops until TurboFan becomes
the default optimiser.

The regression that was detected was when looking at how long it took
to create a new buffer from an array of data.

When using `for (let i=0; i<length; i++) ` we saw the operation take
almost 40% longer compared to `var i=0`.

PR-URL: #5819
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Trevor Norris <trevnorris@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Ref: http://github.com/nodejs/benchmarking/issues/38
MylesBorins pushed a commit that referenced this pull request Mar 30, 2016
Using let in for loops showed a regression in 4.4.0. @ofrobots
suggested that we avoid using let in for loops until TurboFan becomes
the default optimiser.

The regression that was detected was when looking at how long it took
to create a new buffer from an array of data.

When using `for (let i=0; i<length; i++) ` we saw the operation take
almost 40% longer compared to `var i=0`.

PR-URL: #5819
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Trevor Norris <trevnorris@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Ref: http://github.com/nodejs/benchmarking/issues/38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
buffer Issues and PRs related to the buffer subsystem. v8 engine Issues and PRs related to the V8 dependency.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants