-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Properly cache types for shared control flow nodes #41665
Conversation
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the perf test suite on this PR at 3d41c88. You can monitor the build here. Update: The results are in! |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 3d41c88. You can monitor the build here. |
Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 3d41c88. You can monitor the build here. |
@ahejlsberg Here they are:Comparison Report - master..41665
System
Hosts
Scenarios
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
@ahejlsberg Thanks for taking a look at this, it's highly appreciated. The changes in #41408 were deliberately caching up to two shared flow nodes, i.e. the one closest to and furthest from the root. In theory I think there can be arbitrarily many shared candidates that are visited in the tldr; I think the simplification is fine, just wanted to share the reasoning behind the changes in #41408. |
@JoostK With the simplification we'll cache in the last shared node visited, which is the one closest to the "top" of the control flow graph. That should get us the most sharing possible. It may take a few extra loop iterations to hit the cache, but those iterations are cheap--the costly stuff all happens in the recursive calls. Either way, the key insight here is that we sometimes didn't cache at all, and I appreciate you discovering that. It's interesting to see that the fix has little or no effect on our performance suites. I guess the pattern that leads to the exponential slowdown is rare. But then again, if it was more common we'd probably have run into it already. |
@ahejlsberg Thanks for the additional explanation. I would kindly request if this could be backported to 4.1, as the 4.2 release is still 3 months out. |
This looks like a pretty safe backport. @DanielRosenwasser @ahejlsberg thoughts? |
@RyanCavanaugh Yes, this is a very safe fix and I agree we should backport. |
* Properly cache shared flow node types * Add test
* Properly cache shared flow node types * Add test Co-authored-by: Anders Hejlsberg <[email protected]>
Fixes #41124.
Simplified version of #41408. Thanks to @JoostK for diagnosing and proposing a fix.