Fixes#28517.
The npm package info gets requested a bunch of times by deno_npm. Before
this PR, we were loading it from the FS and parsing it each and every
time. With a lot of dependencies (and large `registry.json` files), this
can lead to massive blowups in install times.
From the repro in #28517
before this PR:
```
Command being timed: "deno i"
User time (seconds): 538.54
System time (seconds): 56.49
Percent of CPU this job got: 198%
Elapsed (wall clock) time (h:mm:ss or m:ss): 4:59.45
Maximum resident set size (kbytes): 378976
```
this PR:
```
Command being timed: "deno-this-pr i"
User time (seconds): 1.29
System time (seconds): 1.56
Percent of CPU this job got: 68%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:04.16
Maximum resident set size (kbytes): 500864
```
So roughly an improvement from 339s to 4s. You can see that the max RSS
does increase a decent amount, which is the main downside. However, this
in memory cache is cleared once we're done caching npm packages, and IMO
the performance tradeoff is well worth it.
This also has a very noticable, though less drastic, effect on fresh
installs (no deno.lock) for smaller projects. Here's a clean nextJS
template project:
```
❯ hyperfine --warmup 5 --prepare "rm -rf node_modules deno.lock" "deno i" "deno-this-pr i"
Benchmark 1: deno
Time (mean ± σ): 765.0 ms ± 10.1 ms [User: 622.3 ms, System: 216.4 ms]
Range (min … max): 749.0 ms … 783.6 ms 10 runs
Benchmark 2: deno-this-pr
Time (mean ± σ): 357.2 ms ± 9.4 ms [User: 193.2 ms, System: 198.2 ms]
Range (min … max): 346.4 ms … 374.1 ms 10 runs
Summary
deno-this-pr ran
2.14 ± 0.06 times faster than deno
```
Extracting out more code from the CLI for reuse elsewhere (still more
work to do, but this is a start).
This is the code for extracting npm tarballs and saving information in
the npm cache in the global deno_dir.
2024-12-03 02:10:16 +00:00
Renamed from cli/npm/managed/cache/registry_info.rs (Browse further)
