Performance Opportunities

[bradzacher]

I just wanted to have a publicly visible, centralised list of these somewhere that I can easily reference and add to without having to file an in-depth issue straight away.

Parsing

• Don't construct a single-file ts.Program for non-type-aware parses (feat: remove partial type-information program #6066 - will be released in v6)
  • This step is a leftover from the old no-unused-vars-experimental experiment. But it's wasted effort because a single-file ts.Program is literally useless. We can save time by just building a ts.SourceFile directly.
• Cache parserOptions.project glob resolution for a period of time (feat(typescript-estree): cache project glob resolution #6367).
  • right now we resolve the globs individually for each and every file. This can be really slow - ESP if there are ** globs or a lot of matches!
    If we can cache this computation for a period of time, we can save a bunch of time in the type-aware parse.
    For the persistent case we should be able to use a relatively short-lived cache.
    For the single-run case we should be able to use an infinite cache.
• Investigate building a types API that allows us to do caching (Make a "shortcut" API around TypeScript for node types #6244)
  • My hypothesis is that the TS checker APIs don't do as much caching as we'd like. I think we can more aggressively cache things and save times on repeated requests for types across rules.
  • This may be a uselessly small improvement because (a) the caching TS does is enough, (b) there may little overlap between rules' type requests that caching doesn't help and just uses more memory instead.
• Investigate using scope analysis to fulfill some type info request (Perf research: use scope analysis to circumvent type information for some cases #6217)
  • This would be dependent on us having our own typechecker api (previous point).
  • If we can use scope analysis to return annotated variables, then we wouldn't need to calculate the TS types at all in some cases, which would save a lot of time!
• Support project references (Support for Project References #2094)
  • If we can resolve project references then we can make config easier by automating some config.
  • If we can use .ts files instead of .d.ts files then we can save a lot of time and memory.
• Leverage ts.DocumentRegistry to share resources between ts.Programs
  • If two programs reference the same file (eg both programs need types for node_modules/foo/index.d.ts) then currently there's no sharing done and we'll get two parses and two copies of the types + ts.SourceFile for that module.
    ts.DocumentRegistry is intended to at least share ts.SourceFiles - which could save a significant amount of memory for highly interdependent codebases.
  • feat(typescript-estree): add experimental mode for type-aware linting that uses a language service instead of a builder  #6172 implements this via a ts.LanguageService.
• Change parser conversion logic from a switch/case to a jump table (Repo: investigate switching core TS->ESTree conversion logic from a "switch/case" to a "jump table" for performance improvements #6149)
  • TS saw significant wins from such a change - we probably will too.
• Investigate lazily computing node location (feat(typescript-estree): lazily compute loc #6542 (comment))
  • TS currently lazily computes the source code location for nodes. This means that when we convert the AST we're hit with the cost of TS doing a binary search to convert the string range to the line/col numbers.
  • ESLint doesn't use location for many reasons
  • If we can convert the location computation to a lazy one, then maybe we can save a bunch of time

CLI Runs ("one-and-done" runs)

• Automatically clean up projects when we know they're no longer needed (Cleanup old file/folder watch callbacks #3536)
  • If we know that there are no files left in the project to be linted in a CLI run, then we can delete the project from memory and stop checking it at all. Should save memory and time.
  • I don't know if this is possible to do without being able to (a) tell ESLint what order to lint files in and (b) have ESLint tell us what files are left.
• Implement a CLI that runs ESLint with one thread per project ([RFC] Building a CLI for typescript-eslint #6020 / feat(cli): create initial, proof-of-concept CLI #4359)
  • Continuing on from the last point - if we can't tell ESLint what order to lint in, then we can sit in front of ESLint and make it lint how we need.
  • This would also allow us to parallelise the lint run which further improves the performance.
• Turn on parserOptions.allowAutomaticSingleRunInference by default for all users.
  • We haven't turned this on broadly yet because there are some weird edge-cases where it causes issues (allowAutomaticSingleRunInference causes incorrect type information #6184)
  • We also want to make it more robust so we don't rely on flakey process.argv detection (causing issues like Support pnpm for single run detection #3811). feat: parsing session objects eslint/rfcs#102 would allow us to be infallible!

IDE Runs ("persistent" runs)

• Investigate direct integration with IDE extensions like vscode-eslint. Examples of possible optimisations:
  • Add environment variables so we know that we can attach disk watchers
    • This would allow us to watch files/folders instead of relying on our (really slow) invalidation logic to check for edge-cases.
    • We could also do-away with the various file existence checks and fs.stats.
    • We could actually just rely on TS's in-built disk watching logic instead for most cases.
  • We could corral files into separate threads based on the project they belong to which would improve performance which would save us iterating over all projects in the config to check existence.
• Use ts.LanguageService to manage the program instead of managing a builder/watch program (feat(typescript-estree): add experimental mode for type-aware linting that uses a language service instead of a builder  #6172)
  • The ts.LanguageService is designed to be as efficient as possible and share as much memory as possible so that IDEs are quick and low memory. We might be able to leverage this data-structure ourselves for the same result in persistent runs.

Rules

• naming-convention is a really slow lint rule. We need to profile it to see where the bottlenecks are.
  • This might be a side-effect of the super generic way I wrote it way back when?
  • Maybe due to the fact all selectors fire all the time regardless of if there's a validator for them?
• audit type-aware rules to ensure they're not accessing type information before it's necessary.
  • Some rules were built quickly and naively - there's probably a number of cases where we're using type info when AST-based checks would suffice. AST checks are fast, type info checks are slow.
  • Example: fix(eslint-plugin): [no-implied-eval] improve performance #4313

eslint-plugin-import

There's a lot of things we don't recommend using from this plugin, but perhaps we can improve the performance so people don't have to manually opt-out of things to avoid perf pit-falls.

• Provide an API on context.parserServices to resolve an import to a module based on the file's type information.
  • For a lot of users this is done via eslint-import-resolver-typescript, or for more basic usecases the built-in node resolver.
    These resolvers rely on disk operations which can slow things down.
    If we've got type info - then we've already got all of the required info - so we can potentially help them save time!
• Provide an API on context.parserServices to resolve the exports for a file if there is type information.
  • Some eslint-plugin-import rules do out-of-band parsing of modules to determine their exports. If we've got type information then we don't need to parse - we already have that info.
• Provide an API on context.parserServices to quickly parse a file if there is type information.
  • Right now the plugin will emulate ESLint's parse call in order to attempt to do an out-of-band parse of a file.
    If we've got type info then we could just directly fetch the ts.SourceFile and convert it without going through any of our other pre-parse logic, potentially saving a chunk of time.

eslint-plugin-prettier

This is another case where we generally recommend against using this, however again we might be able to improve the status-quo.

• Improve the prettier API so that instead of passing the raw source code text into prettier which triggers an additional parse using the @typescript-eslint/typescript-estree version included in the package, it can just reuse the existing AST that ESLint gives if the parser versions align.

TypeScript

One major path we're yet to leverage is building within TypeScript itself. Currently we're using the generic APIs that TS has for general purpose usecases, however it's there's an opportunity to work cloesly with the TS team to create a bespoke API for our usecase that more closely matches our constraints and requirements. By building into the TS codebase directly we could leverage many of the internal APIs and data structures that we cannot access externally.

ESLint

ESLint itself is unfortunately not well designed for our stateful parsing. There's opportunity to work closely with the ESLint team to improve the design so that the core logic can better support our stateful nature, which would in turn unlock other potential performance improvements internally for us.

There's two paths for us to take with this collaboration:

• Wait for a complete rewrite of the core system and work closely to ensure that our requirements are included in the new design (Complete rewrite of ESLint eslint/eslint#16557).
• Push the current design forwards as much as we can ahead of any rewrite (eg feat: parsing session objects eslint/rfcs#102).

These paths are not mutually exclusive - we can and should improve the current state whilst also looking to the future as well.

[bradzacher]

It's worth mentioning that we can and should leverage CPU profiling more in our investigations.
It's relatively easy to generate one:

$ node --cpu-prof ./node_modules/.bin/eslint .

or you can isolate to a specific lint rule:

$ node --cpu-prof ./node_modules/.bin/eslint --no-eslintrc --parser="@typescript-eslint/parser" --plugin "@typescript-eslint" --rule "@typescript-eslint/no-unused-vars: [error]" --ext=".ts,.tsx" .

or with a slightly more complicated config in a new config file like:

$ touch .temp.eslintrc.js
# edit file
$ node --cpu-prof ./node_modules/.bin/eslint --no-eslintrc -c .temp.eslintrcjs .

This will generate a .cpuprofile file in the repo root which you can then load into https://www.speedscope.app/ to view the profile in a nice flame graph visualisation.

I've found that switching the graph to "left heavy" mode is best for holistically analysing the performance.
Normal mode = show calls and perf in the exact timeline it occurred
Left heavy = aggregate all calls to show the total time spent in each function during the trace