Only use resolutionStart when pushing resolution stack by jakebailey · Pull Request #58824 · microsoft/TypeScript

Jake Bailey (jakebailey) · 2024-06-10T19:09:16Z

#58337 resets the stack by moving its start up temporarily. However, there are other parts of the checker other than the push/pop circular error code which rely on the stack. It looks like for #58805, isResolvingReturnTypeOfSignature in particular stops knowing that a particular return type is being resolved, causing us to start doing extra work that won't go anywhere.

"Fix" this by always using the full stack for these non-circularity-checking stack users.

To make this more clear, the second commit refactors the code a bit into clear functions that show which do and don't use the full stack.

Perhaps this isn't the right fix; this passes all tests, but maybe we shouldn't be using the stack for anything but circularity checking in push/pop anyway. That's a more invasive change.

Jake Bailey (jakebailey) · 2024-06-10T19:09:30Z

TypeScript Bot (@typescript-bot) test it
TypeScript Bot (@typescript-bot) pack this

TypeScript Bot (typescript-bot) · 2024-06-10T19:09:33Z

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
`test top400`	✅ Started	✅ Results
`user test this`	✅ Started	✅ Results
`run dt`	✅ Started	✅ Results
`perf test this faster`	✅ Started	👀 Results
`pack this`	✅ Started	✅ Results

TypeScript Bot (typescript-bot) · 2024-06-10T19:11:12Z

Hey Jake Bailey (@jakebailey), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
"devDependencies": {
"typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/162158/artifacts?artifactName=tgz&fileId=5467C79554455AB6B7A3891F7AEEC985DDCEC30BC2488FAF842EEF0088B3DA1E02&fileName=/typescript-5.6.0-insiders.20240610.tgz"
}
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.6.0-pr-58824-2".;

TypeScript Bot (typescript-bot) · 2024-06-10T19:29:43Z

Hey Jake Bailey (@jakebailey), the results of running the DT tests are ready.

Everything looks the same!

You can check the log here.

TypeScript Bot (typescript-bot) · 2024-06-10T19:37:10Z

Jake Bailey (@jakebailey) Here are the results of running the user tests with tsc comparing main and refs/pull/58824/merge:

Everything looks good!

TypeScript Bot (typescript-bot) · 2024-06-10T19:45:30Z

Jake Bailey (@jakebailey)
The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Compiler-Unions - node (v18.15.0, x64)}
_Errors	₃₀	₃₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_62,153	_62,153	_~	_~	_~	_{p=1.000 n=6}
_Types	_50,242	_50,242	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{193,006k (± 0.74%)}	_{193,532k (± 0.97%)}	_~	_192,289k	_196,079k	_{p=0.575 n=6}
_{Parse Time}	_{1.31s (± 0.57%)}	_{1.30s (± 0.76%)}	_~	_1.29s	_1.31s	_{p=0.109 n=6}
_{Bind Time}	_0.72s	_0.72s	_~	_~	_~	_{p=1.000 n=6}
_{Check Time}	_{9.64s (± 0.55%)}	_{9.55s (± 0.59%)}	_{-0.09s (- 0.93%)}	_9.47s	_9.64s	_{p=0.020 n=6}
_{Emit Time}	_{2.76s (± 1.06%)}	_{2.76s (± 0.71%)}	_~	_2.73s	_2.78s	_{p=0.935 n=6}
_{Total Time}	_{14.43s (± 0.35%)}	_{14.33s (± 0.30%)}	_{-0.10s (- 0.68%)}	_14.28s	_14.41s	_{p=0.020 n=6}
_{angular-1 - node (v18.15.0, x64)}
_Errors	₅	₅	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_944,109	_943,959	_{-150 (- 0.02%)}	_~	_~	_{p=0.001 n=6}
_Types	_407,049	_407,029	_{-20 (- 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{1,222,225k (± 0.00%)}	_{1,222,184k (± 0.00%)}	_~	_1,222,151k	_1,222,233k	_{p=0.199 n=6}
_{Parse Time}	_{6.77s (± 0.77%)}	_{6.81s (± 0.65%)}	_~	_6.76s	_6.88s	_{p=0.199 n=6}
_{Bind Time}	_{1.88s (± 0.62%)}	_{1.88s (± 0.43%)}	_~	_1.87s	_1.89s	_{p=1.000 n=6}
_{Check Time}	_{31.31s (± 0.18%)}	_{31.32s (± 0.13%)}	_~	_31.27s	_31.38s	_{p=0.936 n=6}
_{Emit Time}	_{15.33s (± 0.17%)}	_{15.30s (± 0.44%)}	_~	_15.20s	_15.38s	_{p=0.748 n=6}
_{Total Time}	_{55.29s (± 0.15%)}	_{55.30s (± 0.22%)}	_~	_55.13s	_55.45s	_{p=0.810 n=6}
_{mui-docs - node (v18.15.0, x64)}
_Errors	₅	₅	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_2,061,575	_2,061,575	_~	_~	_~	_{p=1.000 n=6}
_Types	_905,189	_905,189	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{2,071,941k (± 0.00%)}	_{2,071,943k (± 0.00%)}	_~	_2,071,785k	_2,071,999k	_{p=0.230 n=6}
_{Parse Time}	_{6.83s (± 0.28%)}	_{6.84s (± 0.33%)}	_~	_6.80s	_6.86s	_{p=0.328 n=6}
_{Bind Time}	_{2.30s (± 0.36%)}	_{2.31s (± 0.51%)}	_~	_2.30s	_2.33s	_{p=0.077 n=6}
_{Check Time}	_{69.92s (± 0.33%)}	_{69.98s (± 0.50%)}	_~	_69.60s	_70.47s	_{p=1.000 n=6}
_{Emit Time}	_{0.14s (± 3.60%)}	_0.14s	_~	_~	_~	_{p=0.174 n=6}
_{Total Time}	_{79.19s (± 0.28%)}	_{79.26s (± 0.46%)}	_~	_78.85s	_79.77s	_{p=0.873 n=6}
_{self-build-src - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_1,230,424	_1,230,428	_{+4 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_Types	_261,178	_261,179	_{+1 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{2,351,511k (± 0.05%)}	_{2,351,541k (± 0.05%)}	_~	_2,349,991k	_2,353,599k	_{p=0.936 n=6}
_{Parse Time}	_{4.98s (± 1.38%)}	_{4.97s (± 0.77%)}	_~	_4.92s	_5.00s	_{p=0.873 n=6}
_{Bind Time}	_{1.90s (± 0.43%)}	_{1.90s (± 0.92%)}	_~	_1.87s	_1.91s	_{p=0.730 n=6}
_{Check Time}	_{34.08s (± 0.23%)}	_{34.08s (± 0.23%)}	_~	_34.01s	_34.21s	_{p=0.748 n=6}
_{Emit Time}	_{2.65s (± 3.75%)}	_{2.64s (± 2.46%)}	_~	_2.57s	_2.71s	_{p=0.688 n=6}
_{Total Time}	_{43.63s (± 0.40%)}	_{43.61s (± 0.23%)}	_~	_43.51s	_43.75s	_{p=0.810 n=6}
_{self-build-src-public-api - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_1,230,424	_1,230,428	_{+4 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_Types	_261,178	_261,179	_{+1 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{2,503,829k (± 3.35%)}	_{2,428,341k (± 0.03%)}	_~	_2,427,014k	_2,429,250k	_{p=0.689 n=6}
_{Parse Time}	_{6.22s (± 0.54%)}	_{6.24s (± 1.27%)}	_~	_6.11s	_6.31s	_{p=0.423 n=6}
_{Bind Time}	_{2.02s (± 0.85%)}	_{2.00s (± 0.75%)}	_~	_1.99s	_2.03s	_{p=0.138 n=6}
_{Check Time}	_{40.57s (± 0.30%)}	_{40.62s (± 0.32%)}	_~	_40.44s	_40.80s	_{p=0.521 n=6}
_{Emit Time}	_{3.14s (± 4.11%)}	_{3.12s (± 2.74%)}	_~	_3.01s	_3.27s	_{p=0.689 n=6}
_{Total Time}	_{51.98s (± 0.39%)}	_{52.01s (± 0.39%)}	_~	_51.85s	_52.34s	_{p=0.810 n=6}
_{self-compiler - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_259,181	_259,185	_{+4 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_Types	_105,173	_105,174	_{+1 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{428,784k (± 0.00%)}	_{428,895k (± 0.02%)}	_{+112k (+ 0.03%)}	_428,835k	_429,036k	_{p=0.005 n=6}
_{Parse Time}	_{4.07s (± 0.40%)}	_{4.07s (± 0.63%)}	_~	_4.04s	_4.10s	_{p=0.685 n=6}
_{Bind Time}	_{1.63s (± 1.42%)}	_{1.61s (± 1.16%)}	_~	_1.59s	_1.64s	_{p=0.331 n=6}
_{Check Time}	_{22.29s (± 0.23%)}	_{22.27s (± 0.46%)}	_~	_22.17s	_22.41s	_{p=0.423 n=6}
_{Emit Time}	_{1.72s (± 1.02%)}	_{1.75s (± 0.84%)}	_{+0.02s (+ 1.45%)}	_1.73s	_1.77s	_{p=0.035 n=6}
_{Total Time}	_{29.71s (± 0.14%)}	_{29.70s (± 0.31%)}	_~	_29.59s	_29.84s	_{p=0.748 n=6}
_{ts-pre-modules - node (v18.15.0, x64)}
_Errors	₃₅	₃₅	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_224,565	_224,565	_~	_~	_~	_{p=1.000 n=6}
_Types	_93,734	_93,734	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{369,737k (± 0.02%)}	_{369,783k (± 0.02%)}	_~	_369,649k	_369,877k	_{p=0.298 n=6}
_{Parse Time}	_{2.79s (± 0.29%)}	_{2.79s (± 0.64%)}	_~	_2.77s	_2.82s	_{p=1.000 n=6}
_{Bind Time}	_{1.59s (± 1.05%)}	_{1.59s (± 1.01%)}	_~	_1.57s	_1.61s	_{p=0.935 n=6}
_{Check Time}	_{15.73s (± 0.33%)}	_{15.74s (± 0.54%)}	_~	_15.63s	_15.86s	_{p=0.872 n=6}
_{Emit Time}	_0.00s	_0.00s	_~	_~	_~	_{p=1.000 n=6}
_{Total Time}	_{20.10s (± 0.26%)}	_{20.12s (± 0.47%)}	_~	_20.01s	_20.26s	_{p=0.748 n=6}
_{vscode - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_2,852,851	_2,852,847	_{-4 (- 0.00%)}	_~	_~	_{p=0.001 n=6}
_Types	_967,821	_967,819	_{-2 (- 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{3,024,859k (± 0.00%)}	_{3,024,817k (± 0.00%)}	_~	_3,024,739k	_3,024,882k	_{p=0.335 n=6}
_{Parse Time}	_{13.85s (± 0.19%)}	_{13.84s (± 0.34%)}	_~	_13.78s	_13.89s	_{p=0.747 n=6}
_{Bind Time}	_{4.21s (± 2.01%)}	_{4.24s (± 2.47%)}	_~	_4.16s	_4.38s	_{p=0.867 n=6}
_{Check Time}	_{75.58s (± 2.78%)}	_{74.43s (± 1.94%)}	_~	_73.58s	_77.33s	_{p=0.521 n=6}
_{Emit Time}	_{22.24s (± 8.41%)}	_{23.14s (± 6.38%)}	_~	_20.17s	_23.93s	_{p=1.000 n=6}
_{Total Time}	_{115.88s (± 0.27%)}	_{115.65s (± 0.36%)}	_~	_115.13s	_116.39s	_{p=0.230 n=6}
_{webpack - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_266,899	_266,899	_~	_~	_~	_{p=1.000 n=6}
_Types	_108,686	_108,686	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{412,038k (± 0.01%)}	_{412,029k (± 0.02%)}	_~	_411,942k	_412,119k	_{p=0.810 n=6}
_{Parse Time}	_{4.75s (± 1.16%)}	_{4.77s (± 1.03%)}	_~	_4.73s	_4.85s	_{p=0.624 n=6}
_{Bind Time}	_{2.05s (± 0.60%)}	_{2.05s (± 0.53%)}	_~	_2.04s	_2.07s	_{p=0.487 n=6}
_{Check Time}	_{21.06s (± 0.29%)}	_{21.14s (± 0.24%)}	_{+0.08s (+ 0.36%)}	_21.04s	_21.19s	_{p=0.024 n=6}
_{Emit Time}	_0.00s	_0.00s	_~	_~	_~	_{p=1.000 n=6}
_{Total Time}	_{27.87s (± 0.35%)}	_{27.96s (± 0.30%)}	_~	_27.81s	_28.06s	_{p=0.064 n=6}
_{xstate-main - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_526,436	_526,271	_{-165 (- 0.03%)}	_~	_~	_{p=0.001 n=6}
_Types	_179,425	_179,401	_{-24 (- 0.01%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{464,174k (± 0.07%)}	_{463,952k (± 0.08%)}	_~	_463,483k	_464,358k	_{p=0.298 n=6}
_{Parse Time}	_{3.16s (± 0.84%)}	_{3.15s (± 0.79%)}	_~	_3.12s	_3.18s	_{p=0.685 n=6}
_{Bind Time}	_{1.19s (± 0.69%)}	_{1.18s (± 0.35%)}	_~	_1.18s	_1.19s	_{p=0.248 n=6}
_{Check Time}	_{18.09s (± 0.86%)}	_{18.15s (± 0.80%)}	_~	_17.96s	_18.39s	_{p=0.688 n=6}
_{Emit Time}	_0.00s	_{0.00s (±244.70%)}	_~	_0.00s	_0.02s	_{p=0.405 n=6}
_{Total Time}	_{22.43s (± 0.74%)}	_{22.48s (± 0.61%)}	_~	_22.29s	_22.69s	_{p=0.575 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

Compiler-Unions - node (v18.15.0, x64)
angular-1 - node (v18.15.0, x64)
mui-docs - node (v18.15.0, x64)
self-build-src - node (v18.15.0, x64)
self-build-src-public-api - node (v18.15.0, x64)
self-compiler - node (v18.15.0, x64)
ts-pre-modules - node (v18.15.0, x64)
vscode - node (v18.15.0, x64)
webpack - node (v18.15.0, x64)
xstate-main - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

Developer Information:

Download Benchmarks

TypeScript Bot (typescript-bot) · 2024-06-10T21:00:44Z

Jake Bailey (@jakebailey) Here are the results of running the top 400 repos with tsc comparing main and refs/pull/58824/merge:

Everything looks good!

Daniel Rosenwasser (DanielRosenwasser) · 2024-06-10T23:21:02Z

The perf tests seem to have a decent amount of variance - can you give a clue on what sorts of savings you're seeing specifically on arktype (the report in #58805)?

Jake Bailey (jakebailey) · 2024-06-10T23:42:52Z

Just finished running this:

Benchmark 1: 5.4.5
Time (mean ± σ): 18.920 s ± 0.045 s [User: 18.532 s, System: 0.300 s]
Range (min … max): 18.834 s … 18.980 s 20 runs
Benchmark 2: main
Time (mean ± σ): 20.088 s ± 0.031 s [User: 19.679 s, System: 0.320 s]
Range (min … max): 20.043 s … 20.146 s 20 runs
Benchmark 3: PR
Time (mean ± σ): 19.012 s ± 0.056 s [User: 18.625 s, System: 0.299 s]
Range (min … max): 18.822 s … 19.081 s 20 runs
Summary
5.4.5 ran
1.00 ± 0.00 times faster than PR
1.06 ± 0.00 times faster than main

David Blass (ssalbdivad) · 2024-06-11T09:16:48Z

Jake Bailey (@jakebailey)Daniel Rosenwasser (@DanielRosenwasser) Awesome, this seems to totally address the regression on my end:

5.4.5:
{"checkTime": 8.74,"types": 479804,"instantiations": 2612248}5.5.1-rc{"checkTime": 9.92,"types": 514330,"instantiations": 2812921}fix-58805{"checkTime": 8.66,"types": 483064,"instantiations": 2622889}

Thanks for taking this so seriously. It's ridiculously impressive how well your team integrates real-world perf feedback from across the ecosystem into your dev process.

Anders Hejlsberg (ahejlsberg) · 2024-06-11T13:58:32Z

Hmm, I'm not 100% sure about this one. The whole idea with resolutionStart is that we can temporarily suspend some ongoing work and make it appear it isn't actually in process. But with this change it will appear to be in process sometimes. We're basically letting a subset of potential ghost errors back in, specifically in cases that depend on isInResolutionStack. Those cases aren't too common, but this will definitely make them more unpredictable.

David Blass (ssalbdivad) · 2024-06-11T14:49:18Z

Jake Bailey (@jakebailey) Do we know what led to this change impacting ArkType more than the other repos that were tested?

If it stems from some obscure pattern that is unlikely to exist in other projects, then identifying it will (hopefully) give me a chance to refactor the affected code.

If it stems from something more ubiquitous, it may be worth weighing the more consistent errors Anders Hejlsberg (@ahejlsberg) mentioned against the perf cost if there is no way to provide both.

Jake Bailey (jakebailey) · 2024-06-11T15:00:40Z

I didn't have time to debug further, but my impression is that there's something very specific to signatures here; the new stack resetting happens as a part of resolving a signature, but this check is checking for a resolving signature, more or less. Makes me think that we're pushing onto the stack then shortly after, resetting it such that we forget that we're resolving. (Which is probably clear given the fact that it works once we look past the new start.)

So, it sort of feels it may be the case that there's some way to avoid that.

I plan to look harder when I have a little more time.

Jake Bailey (jakebailey) · 2024-06-11T17:48:04Z

FWIW this regression is measurable with ts-perf (not surprising); 5.4 vs main:

┌─────────────┬────────────────────┬────────────────────┬────────────────────┬──────────┬──────────┬─────────────┐
│ Project │ Baseline │ Current │ Delta │ Best │ Worst │ p-value │
╞═════════════╧════════════════════╧════════════════════╧════════════════════╧══════════╧══════════╧═════════════╡
│ arktype - node (v18.15.0, x64) │
├─────────────┬────────────────────┬────────────────────┬────────────────────┬──────────┬──────────┬─────────────┤
│ Errors │ 0 │ 0 │ ~ │ ~ │ ~ │ p=1.000 n=6 │
│ Symbols │ 1,033,514 │ 1,058,345 │ +24,831 (+ 2.40%) │ ~ │ ~ │ p=0.001 n=6 │
│ Types │ 477,728 │ 504,614 │ +26,886 (+ 5.63%) │ ~ │ ~ │ p=0.001 n=6 │
│ Memory used │ 816,991k (± 0.00%) │ 847,235k (± 0.02%) │ +30,243k (+ 3.70%) │ 847,106k │ 847,534k │ p=0.005 n=6 │
├─────────────┼────────────────────┼────────────────────┼────────────────────┼──────────┼──────────┼─────────────┤
│ Parse Time │ 1.99s (± 0.20%) │ 1.96s (± 0.32%) │ -0.03s (- 1.59%) │ 1.95s │ 1.97s │ p=0.003 n=6 │
│ Bind Time │ 0.82s (± 1.20%) │ 0.81s (± 0.50%) │ ~ │ 0.81s │ 0.82s │ p=0.213 n=6 │
│ Check Time │ 22.02s (± 0.31%) │ 23.43s (± 0.36%) │ +1.40s (+ 6.37%) │ 23.34s │ 23.58s │ p=0.005 n=6 │
│ Emit Time │ 0.00s │ 0.00s │ ~ │ ~ │ ~ │ p=1.000 n=6 │
├─────────────┼────────────────────┼────────────────────┼────────────────────┼──────────┼──────────┼─────────────┤
│ Total Time │ 24.83s (± 0.29%) │ 26.20s (± 0.32%) │ +1.37s (+ 5.50%) │ 26.10s │ 26.35s │ p=0.004 n=6 │
└─────────────┴────────────────────┴────────────────────┴────────────────────┴──────────┴──────────┴─────────────┘

(via microsoft/typescript-benchmarking#73)

David Blass (ssalbdivad) · 2024-06-13T11:07:02Z

Any additional thoughts on either potential plans to address this or ideas about what the culprit may be in the ArkType repo that's causing the performance issues? Is there maybe a broader suite of repos that can be checked for perf changes stemming from this change?

As mentioned, I'm happy to refactor some internal types if need be to accommodate these changes, but I don't have very good intuitions about what code is most likely responsible for the delta.

Daniel Rosenwasser (DanielRosenwasser) · 2024-06-13T17:17:31Z

Any additional thoughts on either potential plans to address this or ideas about what the culprit may be in the ArkType repo that's causing the performance issues?

Jake might, but the only advice I have at the moment is to try @typescript/analyze-trace to figure out specific statements/expressions that may be taking a long time.

David Blass (ssalbdivad) · 2024-06-13T17:29:46Z

Daniel Rosenwasser (@DanielRosenwasser) Would getting some more data on the broader perf impact of that change be valuable so that it's clear the regression that occurred in ArkType is a clear outlier?

From what I understood, the core fix was already an edge case and Jake's PR (which had negligible overhead) apparently still addresses the majority of those cases. I understand wanting to guarantee ideal behavior as often as possible, but a very noticeable performance hit that could potentially occur in other repos as well seems like a hefty price to pay in this case for that extra bit of certainty.

Jake Bailey (jakebailey) · 2024-06-13T22:09:49Z

I am continuing to look at this; doing some extra tracing of the code involved here to try and compare before/after.

Jake Bailey (jakebailey) · 2024-06-13T23:03:00Z

I've instrumented some basic tracing of the push/pop of signatures and isResolvingReturnTypeOfSignature, and it has pretty much confirmed my suspicion; the stack resetting is perfectly placed to cut off the initial push that we're resolving a particular signature.

Here's an example (not "the" example, but one that can fit in one screenshot):

On the left is main, on the right is with #58337 effectively reverted.

We can see that we pushTypeResolution () => hasDomain({}, "b") in getReturnTypeOfSignature for the signature for this node. But then, we drop down into getResolvedSignature, which resets the stack, cutting off that entry. Later calls to isResolvingReturnTypeOfSignature now say that the current signature is not being processed, even though it really is and the stack resetting just happened as a part of that process.

This PR works because it allows isResolvingReturnTypeOfSignature to still see that resolution is in progress for this signature.

If this PR isn't acceptable, then I'm not totally sure what the right fix will be. I was thinking that maybe the stack could only be reset back up until the signature being resolved, but we're resetting in getResolvedSignature, which means that we have a call expression and not the signature (of course), so we can't actually go find the right entry to know where to move the stack start up to.

I also think that using the stack like this for non push-pop circularity checking reasons may itself be the bad thing, but changing that seems challenging.

Maybe the resetting needs to be somewhere other than getResolvedSignature?

Any ideas, people smarter than me? 😄 Anders Hejlsberg (@ahejlsberg)

Jake Bailey (jakebailey) · 2024-06-13T23:06:19Z

Here is the trace: https://gist.github.com/jakebailey/6718e643e3399316962bd8edf53f4558

If you're looking for "expensive" calls, I would search the "main.txt" for \dms$; these are calls which took more than 50ms, and there are 21 of them on main, but only 8 with the revert. That may help find what specific calls could be changed in arktype itself, maybe.

Jake Bailey (jakebailey) · 2024-06-13T23:33:51Z

I am however able to recover maybe 50% of the loss by doing what we do for the variance reset and only doing it once; the comment in the code for the getResolvedSignature reset implies that it happens only once, but I don't think it ended up implemented that way.

Michael Arnaldi (mikearnaldi) · 2024-06-14T04:20:26Z

Daniel Rosenwasser (@DanielRosenwasser) Would getting some more data on the broader perf impact of that change be valuable so that it's clear the regression that occurred in ArkType is a clear outlier?
From what I understood, the core fix was already an edge case and Jake's PR (which had negligible overhead) apparently still addresses the majority of those cases. I understand wanting to guarantee ideal behavior as often as possible, but a very noticeable performance hit that could potentially occur in other repos as well seems like a hefty price to pay in this case for that extra bit of certainty.

Unfortunately that's not the case, only Anders PR addressed the bug, we tested the other proposed fixes and they did not work except for small isolated cases. I would not pick perf over correctness

Jake Bailey (jakebailey) added 2 commits June 10, 2024 12:00

Only use resolutionStart when pushing resolution stack
40200fc

Refactor into func for clarity
3087697

TypeScript Bot (typescript-bot) assigned Jake Bailey (jakebailey)Jun 10, 2024

TypeScript Bot (typescript-bot) added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Jun 10, 2024

Jake Bailey (jakebailey) requested review from Daniel Rosenwasser (DanielRosenwasser), Ryan Cavanaugh (RyanCavanaugh), Anders Hejlsberg (ahejlsberg) and Wesley Wigham (weswigham)June 10, 2024 20:23

Daniel Rosenwasser (DanielRosenwasser) approved these changes Jun 10, 2024
View reviewed changes

Jake Bailey (jakebailey) marked this pull request as draft June 11, 2024 15:01

Merge branch 'main' into fix-58805
c16d449

Jake Bailey (jakebailey) closed this Dec 11, 2025

github-project-automationBot moved this from Needs merge to Done in PR Backlog Dec 11, 2025

Microsoft (microsoft) locked as resolved and limited conversation to collaborators Jun 10, 2026

Uh oh!

Conversation

Jake Bailey (jakebailey) commented Jun 10, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Jake Bailey (jakebailey) commented Jun 10, 2024

Uh oh!

TypeScript Bot (typescript-bot) commented Jun 10, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Jun 10, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TypeScript Bot (typescript-bot) commented Jun 10, 2024

Uh oh!

TypeScript Bot (typescript-bot) commented Jun 10, 2024

Uh oh!

TypeScript Bot (typescript-bot) commented Jun 10, 2024

tsc

Uh oh!

TypeScript Bot (typescript-bot) commented Jun 10, 2024

Uh oh!

Daniel Rosenwasser (DanielRosenwasser) commented Jun 10, 2024

Uh oh!

Jake Bailey (jakebailey) commented Jun 10, 2024

Uh oh!

David Blass (ssalbdivad) commented Jun 11, 2024

Uh oh!

Anders Hejlsberg (ahejlsberg) commented Jun 11, 2024

Uh oh!

David Blass (ssalbdivad) commented Jun 11, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Jake Bailey (jakebailey) commented Jun 11, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Jake Bailey (jakebailey) commented Jun 11, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

David Blass (ssalbdivad) commented Jun 13, 2024

Uh oh!

Daniel Rosenwasser (DanielRosenwasser) commented Jun 13, 2024

Uh oh!

David Blass (ssalbdivad) commented Jun 13, 2024

Uh oh!

Jake Bailey (jakebailey) commented Jun 13, 2024

Uh oh!

Jake Bailey (jakebailey) commented Jun 13, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Jake Bailey (jakebailey) commented Jun 13, 2024

Uh oh!

Jake Bailey (jakebailey) commented Jun 13, 2024

Uh oh!

Michael Arnaldi (mikearnaldi) commented Jun 14, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Jake Bailey (jakebailey) commented Jun 10, 2024•
edited
Loading

TypeScript Bot (typescript-bot) commented Jun 10, 2024•
edited
Loading

TypeScript Bot (typescript-bot) commented Jun 10, 2024•
edited
Loading

David Blass (ssalbdivad) commented Jun 11, 2024•
edited
Loading

Jake Bailey (jakebailey) commented Jun 11, 2024•
edited
Loading

Jake Bailey (jakebailey) commented Jun 11, 2024•
edited
Loading

Jake Bailey (jakebailey) commented Jun 13, 2024•
edited
Loading

Michael Arnaldi (mikearnaldi) commented Jun 14, 2024•
edited
Loading