noEmit slow on Mac M2

[jakebailey]

Discussed in #1060

^{Originally posted by slackerzz June 5, 2025}
I’ve been testing @typescript/native-preview on my MacBook M2 since its release, and it feels slower than tsc.
For instance, on the same codebase, tsc (v5.6.2) gives me:

❯ time npx tsc -p . --noEmit --extendedDiagnostics
Files:                         3193
Lines of Library:             40862
Lines of Definitions:       1750956
Lines of TypeScript:          24634
Lines of JavaScript:            160
Lines of JSON:                   94
Lines of Other:                   0
Identifiers:                1718657
Symbols:                     953103
Types:                        14732
Instantiations:               40044
Memory used:               1399347K
Assignability cache size:      4238
Identity cache size:            151
Subtype cache size:              93
Strict subtype cache size:       44
I/O Read time:                0.65s
Parse time:                   1.67s
ResolveTypeReference time:    0.03s
ResolveModule time:           0.26s
ResolveLibrary time:          0.01s
Program time:                 2.90s
Bind time:                    1.05s
transformTime time:           0.11s
commentTime time:             0.00s
printTime time:               0.14s
Emit time:                    0.14s
Check time:                   0.19s
I/O Write time:               0.00s
Total time:                   4.27s
npx tsc -p . --noEmit --extendedDiagnostics  14,05s user 2,62s system 68% cpu 24,468 total

while withtsgo:

❯ time npx tsgo -p . --noEmit --extendedDiagnostics
Files:              3199
Lines:           1819088
Identifiers:     1720502
Symbols:         1299526
Types:            206149
Instantiations:   726088
Memory used:    1052469K
Memory allocs:  24159741
Parse time:       0.292s
Bind time:        0.044s
Check time:       0.393s
Emit time:        0.000s
Total time:       0.741s
npx tsgo -p . --noEmit --extendedDiagnostics  92,93s user 3,57s system 96% cpu 1:40,31 total

As you can see, tsc reports a total time of 4.27s but actually takes 24.4s, while tsgo reports 0.741s but takes 1 minute and 40 seconds.
What’s going on here?
I also tried the LSP (both in VS Code and Neovim), and it takes several minutes to start and respond to code changes.

[jakebailey]

@slackerzz Can you pass --pprofDir . and then upload the profiles?

[slackerzz]

@slackerzz Can you pass --pprofDir . and then upload the profiles?

22462-cpuprofile.pb.gz
22462-memprofile.pb.gz

[jakebailey]

Hm, it seems like we don't include the time it takes to actually parse out the configs. In your case, you're spending a significant amount of time visiting directories and matching patterns.

What does your tsconfig look like? Do you have a repo we could test?

[jakebailey]

[slackerzz]

Hi @jakebailey, here's my tsconfig.json file:

{
  "compilerOptions": {
    "lib": ["dom", "dom.iterable", "esnext"],
    "target": "ES2017",
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "paths": {
      "@/*": ["./src/*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules", ".next"]
}

sadly, I cannot share this specific repo. It's a nextjs app, I'm going to to some tests and see if I can reproduce the same behaviour

[slackerzz]

@jakebailey I found the issue! In my repo, I had an allure-results folder with 2,010,168 JSON files in it (8.3 GB) 🤯

After some “late spring” cleaning, I now get:

❯ time npx tsgo -p . --noEmit --extendedDiagnostics
Files:              3200
Lines:           1818834
Identifiers:     1720105
Symbols:         1301145
Types:            193320
Instantiations:   620173
Memory used:    1056159K
Memory allocs:   5647497
Parse time:       0.323s
Bind time:        0.049s
Check time:       0.387s
Emit time:        0.000s
Total time:       0.766s
npx tsgo -p . --noEmit --extendedDiagnostics  4,62s user 0,80s system 363% cpu 1,491 total
❯ time npx tsc -p . --noEmit --extendedDiagnostics
Files:                         3194
Lines of Library:             40862
Lines of Definitions:       1750956
Lines of TypeScript:          24380
Lines of JavaScript:            160
Lines of JSON:                   94
Lines of Other:                   0
Identifiers:                1718260
Symbols:                    1123413
Types:                        89380
Instantiations:              312245
Memory used:               1539488K
Assignability cache size:     38083
Identity cache size:           2709
Subtype cache size:             909
Strict subtype cache size:      234
I/O Read time:                0.67s
Parse time:                   1.65s
ResolveTypeReference time:    0.02s
ResolveModule time:           0.27s
ResolveLibrary time:          0.00s
Program time:                 2.89s
Bind time:                    1.07s
transformTime time:           0.11s
commentTime time:             0.00s
printTime time:               0.14s
Emit time:                    0.14s
Check time:                   1.79s
I/O Write time:               0.00s
Total time:                   5.90s
npx tsc -p . --noEmit --extendedDiagnostics  11,76s user 1,01s system 167% cpu 7,648 total

[jakebailey]

Okay, that makes more sense. Can you profile it again? It still seems like there's some time that's not accounted for.

[slackerzz]

76623-memprofile.pb.gz
76623-cpuprofile.pb.gz

---

@jakebailey testing on a clean app created with npx create-next-app I get this:

❯ time npx tsgo -p . --noEmit --extendedDiagnostics
Files:             482
Lines:          153957
Identifiers:    153926
Symbols:        112506
Types:            3442
Instantiations:   3774
Memory used:    91982K
Memory allocs:  435534
Parse time:     0.035s
Bind time:      0.011s
Check time:     0.011s
Emit time:      0.000s
Total time:     0.059s
npx tsgo -p . --noEmit --extendedDiagnostics  0,53s user 0,14s system 143% cpu 0,473 total

so yes, you're right, there is something not taken into account

[jakebailey]

If you retry with the build from last night, the timings printed out should be more accurate.

[jakebailey]

I'm not seeing much interesting in those profiles anymore. The only other thing I would test in your original case is to time it without --extendedDiagnostics, which will actually make it compile faster because it doesn't have to run extra GCs to collect memory stats.