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
```
Ref https://github.com/denoland/deno/issues/26928.
This was originally a warning so potential bugs would be visible. Now
that the code has been working for a while without issues, and since the
warning can be triggered in a valid case (as in the issue above, where
the warnings also hid the real diagnostic), let's downgrade this from a
warning to a debug log.
This pr explicitly enables the `sysinfoapi` feature flag on `winapi` in
`deno_os`, so that `deno_os` and other deno crates that rely on it can
be built independently outside of the workspace on Windows.
Matches Node.js `http.STATUS_CODES` values now. Deno is currently
exporting an enum directly, which 1) adds keys like `BadRequest` and 2)
ships the status-text strings as non-space-delimited values (eg,
`'BadRequest`` instead of `'Bad Request'`)
Signed-off-by: Luke Edwards <luke.edwards05@gmail.com>
Asynciterable as singular means it adds the concept of AsyncIterable to
DOM instead of providing multiple AsyncIterable instances.
Signed-off-by: letianpailove <113023596+letianpailove@users.noreply.github.com>
Speeds up the caching part of this arbitrary `"nodeModulesDir": "auto"`
project by about 22%
We write the tags associated with a given npm package to the
`.initialized` file, so that byonm can correctly resolve tags. When
setting up the node modules dir, we read that file to see if we need to
update the tags.
If we don't have any tags associated with the package though, we can
just check for existence (which is a fair bit faster than trying to
`open` + `read` a file).
```
❯ hyperfine --warmup 3 "deno check src/**/*.ts" "../deno/target/release-lite/deno check src/**/*.ts"
Benchmark 1: deno check src/**/*.ts
Time (mean ± σ): 369.9 ms ± 5.5 ms [User: 286.9 ms, System: 128.9 ms]
Range (min … max): 361.7 ms … 377.7 ms 10 runs
Benchmark 2: ../deno/target/release-lite/deno check src/**/*.ts
Time (mean ± σ): 303.5 ms ± 5.9 ms [User: 210.9 ms, System: 124.5 ms]
Range (min … max): 292.7 ms … 315.0 ms 10 runs
Summary
../deno/target/release-lite/deno check src/**/*.ts ran
1.22 ± 0.03 times faster than deno check src/**/*.ts
```
