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
On the 2026-05-27 benchmarks.vlt.sh chart (pacquet 0.2.12 vs pnpm 11.3.0 vs bun), the lockfile variation — cache wiped, pnpm-lock.yaml present, no node_modules — has pacquet 2–10× slower than bun across the board:
Fixture
pacquet (s)
pnpm
bun
pacquet ÷ pnpm
pacquet ÷ bun
next
4.878
4.377
0.628
1.11×
7.77×
astro
2.509
2.907
0.319
0.86×
7.87×
svelte
1.221
1.618
0.193
0.75×
6.32×
vue
3.181
3.942
0.319
0.81×
9.98×
large
7.694
11.342
2.091
0.68×
3.68×
babylon
24.933
22.250
11.229
1.12×
2.22×
Pacquet is at or just above pnpm here, but bun is 2–10× faster — and the next and babylon cells are also slight regressions vs pnpm.
Variation shape
lockfile.sh populates a fresh pnpm-lock.yaml but wipes both node_modules and the cache. So:
Resolution is skipped (lockfile is authoritative).
Every package needs to be (a) fetched from the registry, (b) extracted into the content-addressable store, (c) linked into node_modules/.pnpm/, (d) hoisted/junctioned into each importer's node_modules/.
The whole gap to bun is in (a) + (b) + (c) + (d). Bun's parallelism / IO efficiency / single-extract-per-tarball path is meaningfully ahead.
Profile pacquet on large × lockfile and vue × lockfile with samply (or cargo flamegraph). The cells are 7.69 s and 3.18 s respectively, long enough to capture good profiles. Compare to a bun profile of the same install.
Likely areas (without having profiled yet):
Tarball extraction concurrency. Pacquet does try_join_all over per-tarball futures; bun may pool extractors against a thread cap that's better matched to the IO subsystem.
Hash verification per file. Pacquet hashes every extracted file at write time; bun checks the tarball signature once and trusts it after.
Scope
lockfile variation across all six fixtures. The next × 1.11× and babylon × 1.12× pnpm regressions plus the 2–10× bun gap collapse together — they're the same code path.
Problem
On the 2026-05-27
benchmarks.vlt.shchart (pacquet 0.2.12vspnpm 11.3.0vsbun), thelockfilevariation — cache wiped,pnpm-lock.yamlpresent, nonode_modules— has pacquet 2–10× slower than bun across the board:nextastrosveltevuelargebabylonPacquet is at or just above pnpm here, but bun is 2–10× faster — and the
nextandbabyloncells are also slight regressions vs pnpm.Variation shape
lockfile.shpopulates a freshpnpm-lock.yamlbut wipes bothnode_modulesand the cache. So:node_modules/.pnpm/, (d) hoisted/junctioned into each importer'snode_modules/.The whole gap to bun is in (a) + (b) + (c) + (d). Bun's parallelism / IO efficiency / single-extract-per-tarball path is meaningfully ahead.
Related issues
pacquet installslower thanpnpm installdue to syscall contention #11851 —pacquet installslower thanpnpm installdue to syscall contention. Same area; thelockfilecell isolates download+extract from resolution.lockfilecell skips packument fetches entirely (lockfile is authoritative), so pacquet: registry metadata fetch issues a single request — port pnpm's retry policy #11841 doesn't apply here.Suggested approach
Profile pacquet on
large × lockfileandvue × lockfilewithsamply(orcargo flamegraph). The cells are 7.69 s and 3.18 s respectively, long enough to capture good profiles. Compare to a bun profile of the same install.Likely areas (without having profiled yet):
try_join_allover per-tarball futures; bun may pool extractors against a thread cap that's better matched to the IO subsystem.mtimewrites during link. The cardinal rule for syscall contention (pacquet:pacquet installslower thanpnpm installdue to syscall contention #11851).Scope
lockfilevariation across all six fixtures. Thenext × 1.11×andbabylon × 1.12×pnpm regressions plus the 2–10× bun gap collapse together — they're the same code path.Tracker: #11902
Written by an agent (Claude Code, claude-opus-4-7).