[BUG] process.report.getReport() is very very slow on win32

[wraithgar]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

According to @dstaley it can take tens of seconds for process.report.getReport to return on a win32 system. The results of this should be cached in some way that doesn't also require hacks to reset that cache during testing.

Expected Behavior

No response

Steps To Reproduce

No response

Environment

No response

[dstaley]

Just adding some additional context I've come across:

• Slow execution time for getReport has been "fixed" in node with the addition of the report.excludeNetwork option. This should be safe to add since it's a noop on older versions of Node.
• Other package managers (yarn and pnpm (via detect-libc)) check the file contents of /usr/bin/ldd for the presence of a glibc string as a shortcut, but that's hacky since the file contents can be literally whatever.

Also, just noting that even if this value is cached, users will still incur the cost of executing process.report.getReport() at least once, which can add upwards of 30s to installation time.

[wraithgar]

I think caching is the right balance of doing things correctly, but as fast as possible inside those parameters. We will not be string pattern matching the ldd bin.

This is at heart a Node.js bug.

[wraithgar]

Even if excludeNetwork made the call much faster this is still probably a good thing to cache since it's not expected to change inside a given runtime, and is called an unbounded number of times based on how many optional dependencies are in your tree that have a libc field.

[wraithgar]

An alternative that would technically work and be correct but is probably not the right path for npm itself would be to use node_gyp and expose a direct call to ctypes.CDLL, which is what node uses under the hood to get that information.

https://github.com/nodejs/node/blob/4ba9f45d991b3d0471bc20fcb1c234898b4aa1d7/tools/gyp/pylib/packaging/_manylinux.py#L117C29-L117C40