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