lib: avoid using Array.prototype.forEach

[jasnell]

Using Array.prototype.forEach() is still significantly slower than traditional array iteration. This PR adds a benchmark and replaces many (but not all) forEach() uses within lib.

 count method rate confidence.interval
5 array 166.1422406 8.76899908
5 forEach 7.5412201 0.48229307
10 array 75.8375035 4.85803234
10 forEach 4.3405191 0.29654176
20 array 32.5185750 2.20360039
20 forEach 2.5431252 0.14517229
100 array 8.9249754 0.44583628
100 forEach 0.5816331 0.03092516

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

lib

[richardlau]

How many forEach's are left? Is it worth having a lint rule to catch?

[bmeurer]

We are aware of this, and work on the Array builtins (forEach, filter, and friends) already started.

[jasnell]

@richardlau ... only a handful but they are either a bit more complicated to refactor or are otherwise not in code that is that performance critical. At this point I don't believe a lint rule is required.

@bmeurer ... yeah, I figured as much :-) It's a significant enough of a gap right now that making this change makes sense. I've separated each changed file into a separate commit so that we can selectively roll back as necessary once performance improvements are made :-)

[joyeecheung]

I am guessing https://bugs.chromium.org/p/v8/issues/detail?id=5269 is the related tracking issue? Just linking stuff :).

EDIT: or maybe this: https://bugs.chromium.org/p/v8/issues/detail?id=1956

[jasnell]

CI: https://ci.nodejs.org/job/node-test-pull-request/6611/

[mscdex]

I think just 'for' would be more descriptive since they are both iterating over an array.

[jasnell]

@mscdex ... I renamed the array to for as suggested and also went ahead and added for-of and for-in variants so that we can track the performance variance on those as well.

[bmeurer]

Relevant upstream bugs are https://bugs.chromium.org/p/v8/issues/detail?id=1956 and https://bugs.chromium.org/p/v8/issues/detail?id=2229. Full parity with for-of/for vs. forEach requires shipping TurboFan for all JS first, so probably V8 5.9 or 6.0 can provide the performance.

[JacksonTian]

Some forEach not in critical path.

[mscdex]

I've always been in favor of replacing all instances of forEach(), even though others have shot it down in previous PRs by others. IMHO there's really no reason to use forEach(), especially since we now have const which (when used carefully) works for most use cases where you want to scope the variable value to each iteration.

[jasnell]

Ping @nodejs/collaborators

[mcollina]

LGTM

[mscdex]

I'm curious why ...args is being used when we're just using it with .apply() which should handle arguments just fine.

[jasnell]

Either way works for me really

[mscdex]

I would vote for changing to using arguments while we're in here.

[mscdex]

Perhaps these could be named a bit clearer, like makeDeprecateGetter() or maybe makeDepGetter(), and similarly with makeSetter().

[cjihrig]

LGTM. Tiniest nit: would you mind using i as the loop variable instead of n. We aren't consistent, but i seems to be used more.

[thefourtheye]

This doesn't use j at all. Wouldn't this be optimized away?

[jasnell]

whoops, this is just a typo

[thefourtheye]

Can we drop writable? By default it is false

[jasnell]

Ok

[thefourtheye]

Hope none of the changes here involve sparse arrays. That would change the semantics of the loop iteration.

[jasnell]

None of the loops appear to involve sparse arrays that I can see.

[jasnell]

@thefourtheye ... updated to address your feedback. PTAL

[jasnell]

ping @thefourtheye

[thefourtheye]

Sorry for the delay. Belated LGTM.

[italoacasas]

@jasnell this PR need backport to v7

[MylesBorins]

+1 for v6.x backport