Performance issues on large repos

[camc314]

The performance of tsgolint is not ideal on large repositories.

For example when linting elastic/kibana, it takes ~214 seconds to lint.
This is split, ~29 seconds working out which tsconfig a file is associated with, and ~185 seconds actually doing the type checking, and linting the file.

2025/10/13 16:22:17.435837 Starting tsgolint
2025/10/13 16:22:17.700397 Starting to assign files to programs. Total files: 76785
2025/10/13 16:22:56.022610 Done assigning files to programs. Total programs: 1210. Unmatched files: 1889
2025/10/13 16:25:51.999390 Linting Complete

This produces a flame graph that looks something like:

Key points are:

• ~27.8% of runtime is spent in GC
• ~112s are spent doing module resolution
• Module resolution is allocating a ridiculous amount of memory

• given the large amount of memory allocated during module resolution, I have the following suspicion:
  • lots of small strings are being allocated e.g. + .ts extension, then + .js extension ect
  • tryExtension is allocating `~135 gb of memory, and appears to be simply concatenating two strings to try to see if the file exists
  • this incredibly large number of small objects being allocated puts a large amount of pressure on the garbage collector (see the first CPU flame graph where a substantial chunk of CPU time is spent in garbage collection

NOTE the above number are only when only the no-floating promises rule is enabled

[Hideman42]

I also experienced super slow aspect and out of memory on a small project ~200 files to lint on a windows 11 Entreprise 24H2 26100.6584
Tsgo on its own run blazing fast with a small memory footprint, oxlint on its own with 300+ rules and the import plugin works well on its own, owlint --type-aware is super slow and explode in memory after a ~20sec even on our small project.

EDIT1: Experimenting on 1 file

• pnpm oxlint --fix --fix-suggestions --quiet -- .\test.js

  Found 0 warnings and 0 errors.
  Finished in 63ms on 1 file using 16 threads.
  

• pnpm oxlint --type-aware --fix --fix-suggestions --quiet -- .\test.js

  Found 1 warning and 0 errors.
  Finished in 64.7s on 1 file using 16 threads.
  

  

EDIT2: I will experiment more later and try to gather some logs if possible

[camc314]

@Hideman42 thanks for sharing, do you mind also sharing:

1. how many tsconfigs your project has
2. the total, peak memory usage
3. can you run tsgolint with OXLINT_TSGOLINT_CPU=tsgolint-cpuprof.pb.gz OXLINT_TSGOLINT_ALLOCS=allocs.pb.gz env vars, and upload the files here (or share on discord).

This should help guide us and give more evidence as to where the exact cause is coming from

[Hideman42]

@camc314

1. I have one tsconfig.json and one tsconfig.e2e.json that should be ignored if not explicitly set in command lines and no nested ones or parent ones
2. It went I thing 3G for the single file experience, I had updated early comment before doing the trace run
3. I cant know if the traces are containing sensitive data as it is mostly binary and a few paths I updated but you can find it privately here Hideman42/TestOxlintTsgo

On a side note something I dont understand, I ran it on absolute path of another project and got no crash while a single relative file completely explode. Maybe you will find a pattern. I will try to experiment more to find when it does or not crash.