Huge memory usage regression: 580 MB in 0.43 → 6300 MB in 0.44

[andersk]

Using Node.js 14.17.5 with NPM 6.14.14 for this reproduction recipe (npx works slightly differently in NPM 7).

$ git clone -b v5.8.1 https://github.com/zulip/zulip-desktop.git
$ cd zulip-desktop
$ npm i
$ rm -rf node_modules/.cache
$ npx -p xo@0.43.0 time xo
…
  110 errors
Command exited with non-zero status 1
45.72user 0.89system 0:28.89elapsed 161%CPU (0avgtext+0avgdata 581408maxresident)k
0inputs+0outputs (0major+155120minor)pagefaults 0swaps
$ rm -rf node_modules/.cache
$ npx -p xo@0.44.0 time xo
…
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
…
Command terminated by signal 6
200.27user 7.35system 1:29.69elapsed 231%CPU (0avgtext+0avgdata 2274772maxresident)k
0inputs+0outputs (0major+717566minor)pagefaults 0swaps
$ rm -rf node_modules/.cache
$ NODE_OPTIONS=--max-old-space-size=8192 npx -p xo@0.44.0 time xo
…
  148 errors
Command exited with non-zero status 1
182.59user 5.34system 1:54.32elapsed 164%CPU (0avgtext+0avgdata 6284536maxresident)k
2808inputs+0outputs (2major+1631648minor)pagefaults 0swaps

I bisected this memory usage regression to e2e715d “Simplify lintFiles (#583)”. Cc @fisker.

[XhmikosR]

@fisker any chance you could have a look at this please? The slowness is quite noticeable. Thanks!

[fisker]

I'm sorry for the regression.

Before, we search config files before lint, this cause problem here, it is also very slow when I want lint a single file, xo look for all config files(include package.json) , even very deep/unrelated config files.

Now we search config file one by one when actually linting. This solves the problem I described above. But I guess this is also the reason causes huge memory usage.

I'm not sure what to do.

[fisker]

Maybe queue the lint jobs can solve it?

[XhmikosR]

I'm not familiar with the codebase to be able to help. Maybe @sindresorhus has a suggestion.

[devinrhode2]

I'm thinking issue is resolved in 0.45.0. I'm not seeing memory crashes.
But, I'm sure there's still ways to speed it up. Takes about a full minute to run yarn xo. Not sure if that's typical or not. Fairly typical react web app, 100% typescript.

[andersk]

@devinrhode2 Not sure why you think that. There are no relevant commits between 0.44.0 and 0.45.0, and the problem still reproduces with the reproduction instructions from my original report.

[devinrhode2]

Hmm.. maybe with node 16.10.0 the crash disappears?

[devinrhode2]

I am noticing the crash with our new nx monorepo with node v16.10.0, but not with a smaller, CRA-based project.
Our NX monorepo has probably 100 tsconfig.json files, not sure if that's a factor though.

[andersk]

Note that, like I alluded to in the report, npx in the NPM 7 distributed with Node.js 16 has a bug where it incorrectly prefers the installed version over the version explicitly provided on the command line (npm/cli#3210).

But, if you account for that (and don’t forget to delete node_modules/.cache), this reproduces equally with Node.js 16.

[devinrhode2]

So, super gross, but would checking in the node_modules/.cache into git work-around the issue in the short-term?

[devinrhode2]

of course you'd need to use v0.43.0 to populate the cache.

Another work-around could be running xo on just sub-sections of our code.

[devinrhode2]

Actually... would checking the ./node_modules/.cache generally be a good idea for shitty/already slow CI/CD pipelines?