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

for ... of replacing for(;;) in library networking code? #31024

Closed
edgework opened this issue Dec 19, 2019 · 8 comments
Closed

for ... of replacing for(;;) in library networking code? #31024

edgework opened this issue Dec 19, 2019 · 8 comments

Comments

@edgework
Copy link

Why was [https://github.com//pull/30958] approved and released in 13.5? It has no real justification and actually has a performance impact. for(;;) will always be the fasted loop.

@trivikr
Copy link
Member

trivikr commented Dec 19, 2019

#30958 only made changes in _http_agent.js
For other files, we added comments to retain for(;;) for performance reasons

Commit: ddedf8e

@Lindsor
Copy link

Lindsor commented Dec 19, 2019

The fact multiple files were updated with a comment saying for(;;) loops kept for performance reasons should be justification enough to not change any loops

@edgework
Copy link
Author

What was the point of this change in the first place? How did it make Node better? Its a waste of time and a performance step back regardless of how small.

@Trott
Copy link
Member

Trott commented Dec 19, 2019

What was the point of this change in the first place? How did it make Node better?

Arguably, it makes the code more readable and thus maintainable. Since it's in a place where there is no measurable performance impact, readability/maintainability can take precedence. Additionally, there's something to be said for favoring idiomatic code.

There are, of course, counterarguments. Perhaps the for...of does not seem more readable to everyone but only people familiar/comfortable with that syntax. (In other words, "idiomatic" is in the eye of the beholder.) Perhaps having a mixture of for...of and for ;; in the code is confusing. And so on.

For me, the most convincing argument against it is probably that cosmetic code changes entail risk of introducing bugs and should have a compelling reason for being introduced in lib code.

These things are tradeoffs and reasonable people can make different decisions about them.

(Personally, I had a mild/minuscule preference for not making the change, but with previous approvals, I'd rather approve-and-land-and-move-on than get mired in a discussion about the merits etc. The cost/benefit of the discussion isn't worth it. And if it's more readable for other folks, that's reason enough.)

@Trott
Copy link
Member

Trott commented Dec 19, 2019

(Also, if the concern is just this one file, a PR changing it back to for ;; is reasonable. It may or may not land, of course. It will be easier to justify if there's a reliable and realistic benchmark to show that the change has a measurable impact on Node.js http performance, but I doubt such a benchmark can be made easily. But as long as the reversion is made with a spirit of constructive collaboration, I imagine it would get at least some support. I'm certainly OK with a "just don't do this in http code" approach, but I'm only one opinion.)

@BridgeAR
Copy link
Member

BridgeAR commented Dec 20, 2019

I would like to add to the performance part:

Loop performance is not an issue anymore as of Node.js version >= 10.x. No matter if it's for (;;), for...of or forEach(). All of those perform about the same due to V8 updates. The comment in the code was probably meant specific for streams. That part is copied 1-1 to become readable-streams which has to support older Node.js versions as well.

But even if there is a tiny performance difference, it would not show up as a real downside for applications, since the actual code running would make up for most of the run time of the loop.

Idiomatic code should be more important than 0.01% performance improvement. Actual performance gains are almost always possible by changing the algorithm in some way - not by using different for loops!

@BridgeAR
Copy link
Member

@BridgeAR
Copy link
Member

Closing. If any collaborator would like to keep this open, please feel free to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants