Skip to content

net: use rest parameters instead of arguments#13472

Closed
tniessen wants to merge 1 commit into
nodejs:masterfrom
tniessen:lets-be-destructive
Closed

net: use rest parameters instead of arguments#13472
tniessen wants to merge 1 commit into
nodejs:masterfrom
tniessen:lets-be-destructive

Conversation

@tniessen

@tniessen tniessen commented Jun 5, 2017

Copy link
Copy Markdown
Member

In v8 5.8, rest parameters are significantly faster than other ways to create an array of the arguments. (And it just looks better.)

Refs: #13430

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

net

In v8 5.8, rest parameters are significantly faster than other ways
to create an array of the arguments.

Refs: nodejs#13430
@nodejs-github-bot nodejs-github-bot added the net Issues and PRs related to the net subsystem. label Jun 5, 2017
@tniessen

tniessen commented Jun 5, 2017

Copy link
Copy Markdown
Member Author

@joyeecheung Just noticed that your comments were probably not supposed to mean rest parameters but actually destructuring of the array args? If so, I am sorry, I will add the comments again.

@mscdex

mscdex commented Jun 5, 2017

Copy link
Copy Markdown
Contributor

From what I'm seeing, rest params are only faster once 5 arguments are passed to a function. This isn't the case for these functions.

@refack

refack commented Jun 5, 2017

Copy link
Copy Markdown
Contributor

@tniessen I'm +1 for readability, but we need to prove it does not come with a performance penalty. IMHO you should run a comparative benchmark (https://github.com/nodejs/node/blob/master/doc/guides/writing-and-running-benchmarks.md)

Re: @mscdex's comment

@refack refack added performance Issues and PRs related to the performance of Node.js. refactor to ES6+ labels Jun 5, 2017
@tniessen

tniessen commented Jun 5, 2017

Copy link
Copy Markdown
Member Author

Mhhh I guess @mscdex is right, I benchmarked with 1000 and 5 arguments, and in both cases rest parameters were faster. I did not expect it to become slower once we hit less than 5 arguments... I have no idea how v8 implemented rest parameters, but I didn't think it could become slower than creating an array by hand and copying the values. Do rest parameters do more than that?

@simonkcleung

Copy link
Copy Markdown

Should arrow function even faster?

@mscdex

mscdex commented Jun 5, 2017

Copy link
Copy Markdown
Contributor

@simonkcleung What do you mean about arrow functions? They can't be used as the prototype functions because you lose the connection to the instance (this).

@refack

refack commented Jun 5, 2017

Copy link
Copy Markdown
Contributor

Do rest parameters do more than that?

I think ...args has an O(1) cost, and for <5 args it's just that a loop is faster (loops have been around longer probably better optimized).

@refack

refack commented Jun 5, 2017

Copy link
Copy Markdown
Contributor

I'd be 💯 with this change if we mark it don't land on 6/7/8 or block on #13263

@refack refack left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM in principle.
Maybe wait with landing until V8 is even better

@simonkcleung

Copy link
Copy Markdown

@mscdex Right. I am just wondering if arguments is not created in arrow function, it should be faster. Anyway, I tested, if I did it correctly, the difference is very small.

@joyeecheung

Copy link
Copy Markdown
Member

@tniessen yes I did mean rest params...just picked the wrong word ;)

This is left as a TODO mostly because V8 does not optimize the common case (fewer arguments) enough yet.

@joyeecheung

Copy link
Copy Markdown
Member

Also for the methods changed here the valid signatures do not take more than 5 args anyway...(you can pass that many args but the ones before the final callback argument will be ignored anyway

@jasnell

jasnell commented Jun 13, 2017

Copy link
Copy Markdown
Member

@cjihrig

cjihrig commented Jun 14, 2017

Copy link
Copy Markdown
Contributor

@jasnell what is the plan for landing this? I thought the discussion was leaning toward "rest params aren't quite good enough yet."

@jasnell

jasnell commented Jun 14, 2017

Copy link
Copy Markdown
Member

Not sure to be honest. I'm happy with letting it sit

@tniessen

Copy link
Copy Markdown
Member Author

I cannot find any discussion about these performance issues apart from this, and that one ends with a commit saying that they "could optimize even further (leading to 8-10x improvements for functions with rest parameters". However, I am not too familiar with v8 internals, so I might just be missing something.

I guess we cannot expect performance improvements anytime soon. Feel free to notify me about any changes :)

@refack

refack commented Jun 16, 2017

Copy link
Copy Markdown
Contributor

Ref: #13729

@tniessen

tniessen commented Aug 8, 2017

Copy link
Copy Markdown
Member Author

@Trott Do you think your #13430 (comment) applies here?

@Trott

Trott commented Aug 8, 2017

Copy link
Copy Markdown
Member

@Trott Do you think your #13430 (comment) applies here?

I don't know. Would have to benchmark the change on master, I suppose. Pinging @davidmarkclements @mcollina in case there are other insights to be added...

@mcollina

mcollina commented Aug 8, 2017

Copy link
Copy Markdown
Member

@Trott yes, this change should be good to go.

Neither of those are in a typical hot path, so I'd say we should not worry anyway.

@mcollina mcollina left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

LGTM

@Trott Trott removed the performance Issues and PRs related to the performance of Node.js. label Aug 8, 2017
@tniessen

tniessen commented Aug 9, 2017

Copy link
Copy Markdown
Member Author

@Trott Quick and dirty benchmark based on 10 million iterations with five arguments:

node v8 spread operator loop gain
8.2.1 5.8.283.41 376427426ms 497823279ms 24%
master 6.0.286.52 259321397ms 293091466ms 12%

The spread operator appears to be faster both in v8 5.8 and 6.0, even though I am a little surprised to see the huge performance gap between master and 8.2.1.

@tniessen tniessen self-assigned this Aug 9, 2017
@tniessen

Copy link
Copy Markdown
Member Author

@Trott

Trott commented Aug 10, 2017

Copy link
Copy Markdown
Member

Windows test failures seem unrelated but a re-run is probably in order just to be sure....

@tniessen

Copy link
Copy Markdown
Member Author

@refack

refack commented Aug 10, 2017

Copy link
Copy Markdown
Contributor

@Trott windows failure in job 9579 are caused by common.refreshTmpDir misfiring. I'm worried... Maybe we need to graceful-fs it.

@tniessen

Copy link
Copy Markdown
Member Author

CI is green, landed in 472a665.

@tniessen tniessen closed this Aug 10, 2017
tniessen added a commit that referenced this pull request Aug 10, 2017
In v8 6.0, rest parameters are significantly faster than other ways to
create an array of the arguments, even for small numbers.

PR-URL: #13472
Refs: #13430
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
addaleax pushed a commit that referenced this pull request Aug 10, 2017
In v8 6.0, rest parameters are significantly faster than other ways to
create an array of the arguments, even for small numbers.

PR-URL: #13472
Refs: #13430
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
@addaleax addaleax mentioned this pull request Aug 13, 2017
@benjamingr benjamingr mentioned this pull request Sep 1, 2017
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

net Issues and PRs related to the net subsystem.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants