Properly cache types for shared control flow nodes #41665
Here they are:
Comparison Report - master..41665
@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.