You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] process.report.getReport() is very very slow on win32 #95
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.
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.
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.
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.
changed the title [-][BUG] process.report.getReport() is very very slow on wsl2[/-][+][BUG] process.report.getReport() is very very slow on win32[/+]on Mar 18, 2024
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.
Activity
dstaley commentedon Mar 18, 2024
Just adding some additional context I've come across:
getReporthas been "fixed" in node with the addition of thereport.excludeNetworkoption. This should be safe to add since it's a noop on older versions of Node./usr/bin/lddfor the presence of aglibcstring 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 commentedon Mar 18, 2024
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
lddbin.This is at heart a Node.js bug.
wraithgar commentedon Mar 18, 2024
Even if
excludeNetworkmade 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 alibcfield.[-][BUG] process.report.getReport() is very very slow on wsl2[/-][+][BUG] process.report.getReport() is very very slow on win32[/+]wraithgar commentedon Mar 18, 2024
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
wraithgar commentedon Sep 11, 2024
report.excludeNetwork is probably the path of least resistance here. We should get that in sooner than later.
fix: skip network requests in report.getReport()