7 ms·

> Instead of waiting 200ms for your npm client to start, it will start immediately. That seems like a pretty big performance problem on Node's part. Wouldn't

> Instead of waiting 200ms for your npm client to start, it will start immediately. That seems like a pretty big performance problem on Node's part. Wouldn't it be better if Node solved this, than people having to use external package managers that may not be so well-integrated into the ecosystem? Thirdly would people even bother using an external package manager because of a 200ms delay? Is that considered acceptable at this point?

rattlesnakedave 5y ago
You presuppose NPM is well integrated with the ecosystem /snark
ratww 5y ago
It would be better, but it might also be borderline impossible or at least extremely difficult. Since Node is open source, anyone is free to try to solve. Maybe it is trivial! In the meantime this is a practical, acceptable solution. > Thirdly would people even bother using an external package manager What do you mean? This tool is not a package manager, it is just a script runner.
- tentacleuno 5y ago
  > It would be better, but it might also be borderline impossible or at least extremely difficult. Out of curiosity, what makes you say that? > What do you mean? This tool is not a package manager, it is just a script runner. Bah, sorry. I had PNPM in mind when I wrote that (which I highly recommend). PNPM doesn't explicitly focus on startup time, but it does majorly improve performance as it caches packages.
  - spion 5y ago
    node has a costly and intertwined init itself, where the startup cost is 50-100ms. On top of that, `npm` similarly has a high startup cost adding to the original node cost. Node apps are very slow to start to run due to synchronous `require` eager-loading all the module files, so there is some re-architecting necessary to get a performant startup time yarn v1 is probably the best of the bunch with startup lag close to pure node (100-150ms) yarn v2 and up can be extremely bad, 1s-3s with medium to large repos, especially with PnP enabled which AFAIK forces eager resolution. pnpm similarly has had troubles starting up quickly. It used to be even slower as it passed the command to `npm` in a suboptimal way. Nowadays its about the same speed as `npm` as it uses `npm` for `run`.
  - deleted 5y ago
    [deleted]
- wwwigham 5y ago
  https://github.com/nodejs/node/issues/35711 https://github.com/nodejs/node/issues/35711 Node's working on it.
  - eyelidlessness 5y ago
    Interesting, I had seen previous work on this and thought they’d already squeezed the available perf juice out of it. Nice to see there’s still more room for improvement on this front. And especially exposing more to userland, I definitely have use cases for that!
Macha 5y ago
It's not solely a node problem. The benchmarked task is starting up a node subprocess, that's what most of the 50ms in the Rust execution is. So npm is adding an additional 150ms + whatever the Rust code takes, beyond shelling out to start a node subprocess.
deleted 5y ago
[deleted]
lucideer 5y ago
I assume when you say "Node" you mean NPM? Just spent a few minutes checking NPM's startup code. For a total run of ~234ms, it spends: ~50ms loading a version-parsing lib, loading JSON metadata containing Node binary version and checking node binaries against some hard-coded compatibility data. Dum doesn't seem to do any such sanity checks, which may be fine if you manually ensure your environment is correctly setup. ~25ms initiating logging (& exception handling). This seems like it could be improved. ~40ms loading config & 2 external dependencies (`which` and `graceful-fs`) - not sure if the config is the reason for slowness. The dependencies bring functionality Dum doesn't seem to need as much as NPM does. I guess the load-perf of the dependencies could be improved, unless it's the config loading causing this. ~80ms checking for updates!!! Absolutely no need to do this on every run - this could be throttled somehow at the very least. The remaining ~40ms is actually running the script --- Update: After looking more closely, it appears the update checking code doesn't actually run every time - it's taking 80ms just to load that code (without doing the actual check - the check is cached)

rattlesnakedave 5y ago

You presuppose NPM is well integrated with the ecosystem /snark

ratww 5y ago

It would be better, but it might also be borderline impossible or at least extremely difficult. Since Node is open source, anyone is free to try to solve. Maybe it is trivial! In the meantime this is a practical, acceptable solution. > Thirdly would people even bother using an external package manager What do you mean? This tool is not a package manager, it is just a script runner.

tentacleuno 5y ago
> It would be better, but it might also be borderline impossible or at least extremely difficult. Out of curiosity, what makes you say that? > What do you mean? This tool is not a package manager, it is just a script runner. Bah, sorry. I had PNPM in mind when I wrote that (which I highly recommend). PNPM doesn't explicitly focus on startup time, but it does majorly improve performance as it caches packages.
- spion 5y ago
  node has a costly and intertwined init itself, where the startup cost is 50-100ms. On top of that, `npm` similarly has a high startup cost adding to the original node cost. Node apps are very slow to start to run due to synchronous `require` eager-loading all the module files, so there is some re-architecting necessary to get a performant startup time yarn v1 is probably the best of the bunch with startup lag close to pure node (100-150ms) yarn v2 and up can be extremely bad, 1s-3s with medium to large repos, especially with PnP enabled which AFAIK forces eager resolution. pnpm similarly has had troubles starting up quickly. It used to be even slower as it passed the command to `npm` in a suboptimal way. Nowadays its about the same speed as `npm` as it uses `npm` for `run`.
- deleted 5y ago
  [deleted]
wwwigham 5y ago
https://github.com/nodejs/node/issues/35711 https://github.com/nodejs/node/issues/35711 Node's working on it.
- eyelidlessness 5y ago
  Interesting, I had seen previous work on this and thought they’d already squeezed the available perf juice out of it. Nice to see there’s still more room for improvement on this front. And especially exposing more to userland, I definitely have use cases for that!

Macha 5y ago

It's not solely a node problem. The benchmarked task is starting up a node subprocess, that's what most of the 50ms in the Rust execution is. So npm is adding an additional 150ms + whatever the Rust code takes, beyond shelling out to start a node subprocess.

deleted 5y ago

[deleted]

lucideer 5y ago

I assume when you say "Node" you mean NPM? Just spent a few minutes checking NPM's startup code. For a total run of ~234ms, it spends: ~50ms loading a version-parsing lib, loading JSON metadata containing Node binary version and checking node binaries against some hard-coded compatibility data. Dum doesn't seem to do any such sanity checks, which may be fine if you manually ensure your environment is correctly setup. ~25ms initiating logging (& exception handling). This seems like it could be improved. ~40ms loading config & 2 external dependencies (`which` and `graceful-fs`) - not sure if the config is the reason for slowness. The dependencies bring functionality Dum doesn't seem to need as much as NPM does. I guess the load-perf of the dependencies could be improved, unless it's the config loading causing this. ~80ms checking for updates!!! Absolutely no need to do this on every run - this could be throttled somehow at the very least. The remaining ~40ms is actually running the script --- Update: After looking more closely, it appears the update checking code doesn't actually run every time - it's taking 80ms just to load that code (without doing the actual check - the check is cached)