'pnpm install' Too slow

Verify latest release

• [X] I verified that the issue exists in the latest pnpm release

pnpm version

8.7.6

Which area(s) of pnpm are affected? (leave empty if unsure)

Dependencies resolver, CLI, Lockfile

Link to the code that reproduces this issue or a replay of the bug

No response

Reproduction steps

1. Create a react app using pnpm
2. Run pnpm install
3. Delete node_modules folder
4. Run pnpm install again

Describe the Bug

After removing the 'node modules' directory, running 'pnpm install' again is very slow

Expected Behavior

Running 'pnpm install' again should be done very quickly

Which Node.js version are you using?

v16.20.2

Which operating systems have you used?

• [ ] macOS
• [X] Windows
• [ ] Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

No response

It's also slow on linux. I am on debian Debian GNU/Linux 12 (bookworm) and it used to be very fast earlier now its painfully slow. Takes like 4m 29.1s and it's not even downloading stuff. But even if it was I have a fast consistent network speed of 200mbps so that is definitely not an issue.

Also listing my hardware incase: Intel® Core™ i5-10400 16.0 GiB

Edit: Just tried installing a single package even that took 2m 23s lol

this also happens for me in 8.10.5

PS D:\coding\svelte\some-project> npm-check-updates -u -x re*
Using pnpm
Upgrading D:\coding\svelte\some-project\package.json
[====================] 32/32 100%

 @types/node  ^20.9.4  →  ^20.9.5

Run pnpm install to install new versions.
PS D:\coding\svelte\some-project> pnpm i
Packages: +2 -2
++--
Progress: resolved 436, reused 381, downloaded 1, added 2, done
    ├── ✕ unmet peer vite@^4.0.0: found 5.0.2
    └─┬ @sveltejs/vite-plugin-svelte-inspector 1.0.4
      └── ✕ unmet peer vite@^4.0.0: found 5.0.2

Done in 6m 51.4s

let me know if any more information is needed

I am on Windows and on pnpm version 8.6.7 and it is still very slow despite my internet speed being 150 MBps

maybe its due to your disk read write speeds.. because pnpm copies half of the files/folders from .pnpm-store So if you're on a HDD it'll be really slow as compared to being on SSDs.

could be a possibility, yeah

maybe its due to your disk read write speeds.. because pnpm copies half of the files/folders from .pnpm-store So if you're on a HDD it'll be really slow as compared to being on SSDs.

that's what happened to me when i had .pnpm store on the HDD it was so slow i got it fixed by switching the pnpm store back to the ssd drive

but you cannot soft/hard-link files across drives on windows, no?

I just experienced this. I'm on Manjaro linux. And my disk is SSD of MacBook Pro.

✗ pnpm --version 8.13.1

✗ pnpm install babel-loader @babel/core @babel/preset-react @babel/preset-env --save-dev

 WARN  25 deprecated subdependencies found: @babel/[email protected], @babel/[email protected], @babel/[email protected], @babel/[email protected], @babel/[email protected], @babel/[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Already up to date Progress: resolved 1689, reused 1687, downloaded 0, added 0, done

dependencies:

• @babel/core 7.23.6
• babel-loader 9.1.3

devDependencies:

• @babel/core 7.23.6
• @babel/preset-env 7.23.6
• @babel/preset-react 7.23.3
• babel-loader 9.1.3

 WARN  Issues with peer dependencies found . ├─┬ react-scripts 5.0.1 │ └── ✕ unmet peer typescript@"^3.2.1 || ^4": found 5.3.3 └─┬ optimize-css-assets-webpack-plugin 6.0.1 └── ✕ unmet peer webpack@^4.0.0: found 5.89.0

Done in 5m 32.1s

same on MacBookPro M2

pnpm version : 8.7.6

I believe the assumption being made here is that you WILL be using this tool on an SSD drive without any antivirus programs active. In this screenshot, you see it running on a platter, and has been running pnpm install on the first app (app-01) in the webpack module federation examples, comprehensive react 18 demo... FOR OVER AN HOUR... still not finished yet.

the same as me

Same

Any solution for this?

i mean, there is --prefer-offline, which emulates basically what bun install does. it has some drawbacks. read about the comparison here: https://twitter.com/youyuxi/status/1701243750666703338?s=46&t=22eoAstJVk5l46KQXYEk5Q&utm_source=nodeland&utm_medium=email&utm_campaign=my-thoughts-on-bun

there is also the upcoming vlt package index and manager, that promises better performance. however, it's just in concept stage right now. https://twitter.com/vltpkg

Same. I used disk defragmenter for HDD, but it was still unbearably slow. In SDD disk,the speed is very fast.

I executed the "add" command once after that.I used the "--reporter=ndjson" parameter, where the top 10 slowest items are: (Some key fields, and the consuming field was created,the total time was 5 minutes and 23 seconds)

[
  {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/core-js/3.36.1",
    "status": "found_in_store",
    "consuming": "40.681s"
  },
  {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/lodash/4.17.21",
    "status": "found_in_store",
    "consuming": "36.071s"
  },
  {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/ajv/8.12.0",
    "status": "found_in_store",
    "consuming": "21.17s"
  },
  {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/es-abstract/1.23.3",
    "status": "found_in_store",
    "consuming": "17.975s"
  },
  {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/ajv-keywords/5.1.0",
    "status": "found_in_store",
    "consuming": "4.18s"
  },
  {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/json-schema-traverse/0.4.1",
    "status": "found_in_store",
    "consuming": "3.748s"
  },
  {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/neo-async/2.6.2",
    "status": "found_in_store",
    "consuming": "2.75s"
  },
  {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/@sinclair/typebox/0.27.8",
    "status": "found_in_store",
    "consuming": "2.533s"
  },
  {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/human-signals/2.1.0",
    "status": "found_in_store",
    "consuming": "2.37s"
  },
 {
    "name": "pnpm:progress",
    "packageId": "registry.npmmirror.com/@babel/compat-data/7.24.4",
    "status": "found_in_store",
    "consuming": "2.122s"
  }
]

I'm using pnpm 9.1.0 on a NVMe drive and still having the same problem. I'm running Fedora 40.

Same issue here, if I try to use pnpm in a HDD it takes +30 minutes to install in big projects, yarn takes few minutes.

In my case is unusable because time different are massive when I use it between a SSD and HDD.

You can try reducing the number of the network-concurrency setting to see if it helps.

I don't think I ever used HDD with pnpm. Antiviruses are known for locking files during installation, which significantly slow pnpm down.

I would still expect pnpm to be faster than Yarn and npm in these cases. Unless you use Yarn with Plug'n'play. Yarn PnP might be faster as it writes the packages into zip files, so there are less file system operations.

Also, this issue doesn't seem useful. pnpm is too slow is too broad... pnpm is not slow as we regularly benchmark it and the competitors do as well. It could be slow in some scenarios or situations. If you have a concrete reproducible scenario, we can look into it. But with this title and description the issue just attracts people with different unrelated issues.