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

[edgework]

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]

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

Commit: ddedf8e

[Lindsor]

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]

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]

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]

(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]

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]

I say that as someone who did numerous performance optimizations in core.

[BridgeAR]

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