`transformTime` performance regression since 5.6.x

[valentinmelusson]

Context
Issue was discovered when updating typescript from 5.5.4 to 5.7.3 for our frontend repository at Datadog, after checking our typecheck graph where you can see the global bump :

We have ~9.7M lines of typescript code. We won't be able to give a repro case as this occurred on our whole codebase, but we'll try to give as much detail as possible.

Regression
To typecheck our codebase, we first typecheck our packages (by package we mean small independents folders with their own tsconfig.json and package.json), and build the .d.ts files for each one of them. We then run typecheck on the rest of our codebase, which is a monolith, in build mode to use the previously built declaration files. The part that undergo an increase in time is the last one, on the monolith. The typecheck job for packages remained stable.

We are collecting extended diagnostics metrics when running our typecheck jobs to be able to monitor the different phase.
After investigation, we discovered that the biggest part of this newly added extra-time was due to the transformTime phase going from none in 5.5.4 to ~4min20s after updating to 5.7.3, even though we are setting noEmit:true and emitDeclarationOnly:false. (this transform phase was previously skipped).
There was no modification in any compiler options during this update.

Here is a visual representation of the time bump on our Datadog graphs (as detailed in the legend, the yellow part is the transformTime) :

Potential source
After taking a look at the changes between the said versions, we found this PR that apparently updated the compiler to always emit declarations even with --noEmit, to fix some correctness issues (so that --noEmit still shows declaration diagnostics)

• On 5.5.4, transformTime was not even appearing in the extended diagnostic report

• On 5.6.2, the ~4min20s were in the report, under the transformTime time field (here it's the local run, so it's only ~3min ) :

We have tried to modify some compiler options without success, and we haven't found an official flag to revert to the old compiler behavior in order to avoid this extra time while staying on the updated 5.7.3 version. We don't have other idea for a short term solution, hence this issue.

Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

[RyanCavanaugh]

Can you use every-ts to narrow this down to a specific commit? That would be extremely helpful in terms of figuring out next steps

[valentinmelusson]

👋 @RyanCavanaugh

I narrowed it down to a specific version : 5.6.0-beta. Right before this version (5.5.4), transformTime is not even appearing, while it is appearing in 5.6.0-beta.

I wasn't able to use every-ts to find the specific commit because this occurs when we are trying to build a project using pre-computed declaration files, but it seems that every-ts tsc or every-ts exec tsc are not using these declaration files even though they exist, therefore re-building all projects and this distorts the results of the extendedDiagnostics

Though, by looking a the commits that were applied between the 2 versions mentioned earlier and the related changes, it look likes the most probable "suspect" would be this commit.

Let us know if there is a way to give you more helpful details.

[jakebailey]

Just to be clear, the way declaration errors work is to run the full declaration transform and then report the errors generated during that transform; even if you've disabled emit in general, we still have to run things to get the errors, such that flipping emit on and off doesn't change them (which is critical for a flag like isolatedDeclarations, as an example).

[GGomez99]

Hello! Are there some updates on this investigation, or is this increased transformTime expected and not possible to reduce?
Additionally, the original post was about our TS timings in CI, but we also noticed a performance regression in the IDE. The projectLoadingFinish p95 event duration was below the 5s, and it is now above that threshold after the update:

For info, most developers at our company are using the latest version of VSCode (1.96.2).

Let us know if you need more infos or help on this investigation!

[jakebailey]

There is not. If there were, it'd be posted here.

If you can reproduce it, a full bisect would still be helpful, but I suspect the guess above to have been correct mostly. Declaration error calculation is inseparable from a full declaration emit transform.

I will say that if that commit were all of the problem, I would have expected the graph in the original post to attribute all of the time to the transform, but seemingly the check time increased too, so this may not be the entire story. A full bisect or graph over multiple commits of the TS compiler would be helpful. That or, a repro.

[GGomez99]

Hey @jakebailey, thank you for your answer and sorry for the late response 🙇

After tinkering a bit our monorepo, we were able to run a full bisect and we identified a single culprit commit, which seems to be the one that @valentinmelusson guessed in his answer:

Commit Hash	TS Version	Build Time (s)	Build Time Without transformTime (s)	Report
1b867c5 (commit just before)	5.6.0-dev	375.94	375.94	report
22bbe86 (culprit)	5.6.0-dev	898.79	543.33	report

A detailed report can be found in this repo: https://github.com/GGomez99/ts-bisector?tab=readme-ov-file#ts-bisector
Let us know if you need additional informations, thank you very much for your time 🙏

[jakebailey]

Thanks. Copying the relevant image from your repo here to note it:

Unfortunately, that means this change is in fact all of the problem.

[GGomez99]

If I understand correctly, this performance regression is the side-effect of a new behavior in TS to support new features like isolatedDeclaration ? Is there anything we could do to work around this or to improve our performance ?

[jakebailey]

I am not really aware of anything, except maybe patching TS to disable declaration errors entirely?

I'm not sure if we do it or not, but I'm wondering if we are smart about not bothering to check these diagnostics on files that won't be emitted.

[SudevAtST]

Is there any plan to address this issue in upcoming releases?
One of projects we're working has huge set of files and buildtimes are now hurting us badly.

[RyanCavanaugh]

~All of our performance work is focused on typescript-go at the moment. If 5.6 is available to you and 7.0 will be ~10x faster it's unlikely we'd investigate a fix that would be specific to 6.0. I'd recommend trying the typescript-go native preview and see if you're able to switch yet (if not, let us know what's blocking)