Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler API (language service) becomes incredibly slow when noEmitOnError = true #24444

Closed
AlCalzone opened this issue May 28, 2018 · 5 comments
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@AlCalzone
Copy link
Contributor

AlCalzone commented May 28, 2018

TypeScript Version: 3.0.0-dev.20180526

Search Terms: compiler api noEmitOnError

I'm building an in-memory version of the TypeScript compiler using the language service API. This allows to compile and generate declarations for files that never reach the hard disk. While debugging another issue, I found that setting noEmitOnError to true drastically increases compile times with minor changes to the compiled sources.
I'm not 100% sure that the problem doesn't come from me misusing the API, so forgive me if this is actually not an issue in TypeScript.

Code
This is too much for a short repro, so I created a repro repo here:
https://github.com/AlCalzone/virtual-tsc/tree/ts-repro
To reproduce, npm install and then npm test. The project will run a few simple compilations using the language service API. It contains two identical test cases, where one has noEmitOnError = true and the other one false.

Both test cases correctly compile correct code and both catch syntax errors.

Expected behavior:
Similar results for both.

Actual behavior:

  compiler API repro =>
    √ noEmitOnError = false (2265ms)
    √ noEmitOnError = true (13794ms)
  2 passing (16s)

Related Issues: none found

@RyanCavanaugh RyanCavanaugh added the Bug A bug in TypeScript label May 29, 2018
@RyanCavanaugh
Copy link
Member

Didn't see anything obviously wrong with the way things were being called.

It'd be great if you could identify when this regressed

@AlCalzone
Copy link
Contributor Author

AlCalzone commented May 29, 2018

TS 2.9.0-RC:

  compiler API repro =>
    √ noEmitOnError = false (2319ms)
    √ noEmitOnError = true (13683ms)

TS 2.8.3:

  compiler API repro =>
    √ noEmitOnError = false (2335ms)
    √ noEmitOnError = true (13755ms)

TS 2.7.2:

  compiler API repro =>
    √ noEmitOnError = false (2021ms)
    √ noEmitOnError = true (13184ms)

TS 2.6.2:

  compiler API repro =>
    √ noEmitOnError = false (1580ms)
    √ noEmitOnError = true (10238ms)

TS 2.5.3:

  compiler API repro =>
    √ noEmitOnError = false (1526ms)
    √ noEmitOnError = true (7848ms)

TS 2.4.2:
(with different signature of ServiceHost.readDirectory)

  compiler API repro =>
    √ noEmitOnError = false (1546ms)
    √ noEmitOnError = true (7726ms)

TS 2.3.4:

  compiler API repro =>
    √ noEmitOnError = false (1538ms)
    √ noEmitOnError = true (7241ms)

TS 2.2.2:

  compiler API repro =>
    √ noEmitOnError = false (1049ms)
    √ noEmitOnError = true (3772ms)

TS 2.1.6:

  compiler API repro =>
    √ noEmitOnError = false (1063ms)
    √ noEmitOnError = true (3530ms)

TS 2.0 doesn't work.

@mhegazy mhegazy added this to the TypeScript 3.0 milestone May 29, 2018
@sheetalkamat
Copy link
Member

The time spent in noEmitOnError is in calculation of declaration diagnostics which isn't done if noEmitOnError is false.
In the test, declaration = true for compiler options (link) is set and that's the reason you are seeing this.

@mhegazy mhegazy added Design Limitation Constraints of the existing architecture prevent this from being fixed and removed Bug A bug in TypeScript labels May 29, 2018
@mhegazy mhegazy removed this from the TypeScript 3.0 milestone May 29, 2018
@AlCalzone
Copy link
Contributor Author

AlCalzone commented May 30, 2018

What exactly do you mean by "declaration diagnostics"?

Since I do need the declarations, is there a better way to detect that the compilation had errors than setting noEmitOnError to true and spending an extra 10 seconds? Or in other words: is it enough to test if there are any diagnostics with type === "error" to know that the compiled program will most likely not run?

I still find it weird that the time needed for that almost doubled from 2.5 to 2.7. Also when I try to reproduce the test manually using the tsc CLI, both settings for noEmitOnError take roughly 2 seconds.

AlCalzone added a commit to AlCalzone/virtual-tsc that referenced this issue May 30, 2018
See microsoft/TypeScript#24444 for the reason.
Errors are detected by checking the diagnostic types and emit is skipped
"manually", depending on that check result.
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

5 participants