Performance issue with project service

[Boshen]

Testing in rolldown/rolldown#5660

With tsgolint:

Finished in 6.0s on 318 files with 103 rules using 8 threads.

without:

Finished in 198ms on 318 files with 103 rules using 8 threads.

Haven't started profiling yet, but it feels like it got slower with the addition of project services.

[Boshen]

From @auvred, preliminary profile shows tsgo's (*project.Service).OpenFile appears to be bottleneck.

Maybe project service in tsgo isn’t even intended for single run mode, or perhaps it’s a feature that’s not finished yet

[jakebailey]

This entire thing is going to change (microsoft/typescript-go#1505), so I'm not sure you should rely on it. But I guess the same thing could be said about the whole codebase...

[jakebailey]

That being said I'm not surprised if you're just repeatedly calling OpenFile, especially if the files are ending up in an inferred project. It wouldn't be much different with the old codebase...

[Boshen]

This entire thing is going to change (microsoft/typescript-go#1505), so I'm not sure you should rely on it. But I guess the same thing could be said about the whole codebase...

That being said I'm not surprised if you're just repeatedly calling OpenFile, especially if the files are ending up in an inferred project. It wouldn't be much different with the old codebase...

You are watching 👀 But thank you for the response!

And yes, we are going to try and patch things from our end, adjusting to your changes. We won't raise any issues to the tsgo repo if we are using internal APIs.

[Boshen]

Update: despite the wrong project service architecture, @camc314's PRs to tsgo:

• fix: improve panic message for unspecified ScriptKind in Parser::initializeState microsoft/typescript-go#1556
• perf(tspath): optimize the fast path case for ToFileNameLowerCase microsoft/typescript-go#1558
• perf(tspath): optimize hasRelativePathSegment microsoft/typescript-go#1569
• perf(tspath): avoid string copy in ToFileNameLowerCase microsoft/typescript-go#1575

Reduced execution time from ~90s to 45s, a 2x improvement.

[camc314]

Based on a discussion I've had with Boshen, we've decided to take the following approach:

Current Architecture (headless mode)

1. Read config from stdin with file paths and rules.
2. For each file:
   a. Read the file
   b. service.OpenFile()
   c. EnsureDefaultProjectForFile
   d. get program and source file
3. Group files by program
4. Run linter in parallel.

Currently, in some extremely large project (toeverything/AFFiNE, elastic/kibana, etc), tsgolint chokes, with service.OpenFile() and EnsureDefaultProjectForFile taking a very long time. It also consumes a large amount of memory, often leading to OOM errors, or using the swap, hammering the disk, tanking performance.

We are also seeing a considerable amount of time spent by Go's garbage collector, due to very large number of small objects being created during the above steps.

Proposed Architecture

Given these changes, we are going to remove the use of project services, instead, group files by tsconfig (program) upfront, and then run tsgolint on each group of files (effectively the same as the pre-headless mode).

This will mean that the new flow looks something like:

1. Read config from stdin with file paths and rules.
2. For each file:
   a. Identify the tsconfig (program) for the file.
   b. Group files by tsconfig.
3. For each tsconfig group:
   a. run tsgolint on the group of files.

Since we are no longer using project services, we will not be calling service.OpenFile() or EnsureDefaultProjectForFile, which should significantly reduce memory usage and improve performance.

However this approach means that some ASTs will be parsed multiple times, as we will not be sharing the program across files in the same tsconfig. Given that tsgolint appears fast enough in the majority of cases (non headless mode), this should not be a significant issue, however in future, we will introduce a caching mechanism to avoid re-parsing ASTs.

[Boshen]

Continue in #107