lib: improve lazy loading

[BridgeAR]

The function call plus the existence check is more expensive than inlining the lazy require.

A few lazyAssert calls were obsolete as the assert would have to be required before.

I also moved a few lazy requires in the specific code path as it would not be required at all in some cases.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

lib

[refack]

I don't like it as is. It spreads the require / process.binding, making it hard to audit dependencies.
What you could do is, close to the top:

Object.defineProperty(this,'lasyErrors',{get(){constvalue=require('errors');Object.defineProperty(this,'lasyErrors',{value});returnvalue;});

[Fishrock123]

Does this expense actually add up to anything significant in a realistic scenario?

[BridgeAR]

@refack I guess you mean something like the following?

constlazy={};Object.defineProperty(lazy,'util',{configurable: true,get(){constvalue=require('util');Object.defineProperty(lazy,'util',{ value,enumerable: true});returnvalue;}});constutil=lazy.util;

I know that spreading is not nice but if it's a function call or not is not much of a difference in that case.

@Fishrock123 I'll run some benchmarks later on. I just checked the different lazy loading times them self and those are way faster.

[refack]

I know that spreading is not nice but if it's a function call or not is not much of a difference in that case.

I agree that dynamically it's the same, the difference is in static analysis, if it's a function (or property) at the top it's easier to spot, visually or with tools.

As for a property you can set it on the module or on an explicit lazy holder. Then use modules.util or lazy.util all over

[refack]

Actually lazy is a better choice (I keep discovering that and forgetting it):

constlazy={getutil(){constvalue=require('util');Object.defineProperty(this,'util',{ value,enumerable: true});returnvalue;},
...
}

[jasnell]

Overall I'm not a fan. I prefer to keep lazy loading only when absolutely necessary, mostly to avoid circular references caused by early loading.

[refack]

Re #14167 (comment) comment this could be inlined.

[refack]

Inline

[refack]

errors can be inlined

[refack]

Simpler which is definitely better 👍
What about the lazy property holder? Should be performant, and readable...

[BridgeAR]

@refack there's still the property lookup and it is still faster to just check if the variable is defined or not. This was the way how lazy loading was used in other spots as well and with the simple if it should hopefully be readable again.

[refack]

@refack there's still the property lookup and it is still faster to just check if the variable is defined or not. This was the way how lazy loading was used in other spots as well and with the simple if it should hopefully be readable again.

Ack
(but only because we took a %200 startup slowdown hit and have been chasing timing out tests all day 😉)

[BridgeAR]

This could probably be required up front as well but cluster is likely not required in many places that use net and therefore I kept it as is.

[refack]

So could you document that:

// `cluster` is only used by `listenInCluster` so for startup performance// reasons it's lazy loaded.

[TimothyGu]

LGTM.

Aside from this PR, I'm not too big of a fan of using assert in the code base anywhere other than in tests. Unlike assert(3), the module is unnecessarily big for something that can usually be done in two lines.

[BridgeAR]

@refack I added the comment.

I also moved a statement to prevent lazy loading under some conditions.

[refack]

The link to the CI: https://ci.nodejs.org/job/node-test-commit/11256/ ✔️

[refack]

Landed in b55ab01

[addaleax]

This doesn’t land cleanly on 8.x; if you can, please follow the guide and raise a backport PR, if you don’t think it make sense let me know and we’ll add the dont-land-on label.

[jasnell]

Ping @BridgeAR .. re: backport.

[MylesBorins]

Should this be backported to v6.x-staging? If yes please follow the guide and raise a backport PR, if not let me know or add the dont-land-on label.

[BridgeAR]

I do not see the necessity to backport this. So I changed the labels accordingly.