mirror of
https://github.com/denoland/deno.git
synced 2025-07-08 05:45:07 +00:00
3bc4206274
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 ``` |
||
|---|---|---|
| .. | ||
| deno | ||
| node | ||
| npm_cache | ||