-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
cache the results of type projection and normalization #20304
Comments
cc me (this seems to take 10% of no-opt time). |
Which functions in the compiler need to be memoized? |
I was thinking about implementing this but I have run into some trouble. From what I can gather it is possible for type inference to try multiple different alternatives before it finds the correct typing. This means that types returned after normalizing and selecting associated types may actually be wrong and thus cannot be cached. Is there some way/place where it is known that the result of normalizing is actually the correct way so that caching can be done correctly? The other way I thought of doing it is to rely on the snapshoting in the InferCtxt so that bad types can be rolled back but my implementation still seems to cache bad types in that implementation. |
It's worth nothing that over the last week or so I've been drawing up plans On Mon, Mar 7, 2016 at 12:10 PM, Markus Westerlind <[email protected]
|
I will hold off working on this then. Looking forward to seeing this issue resolved. |
So, actually, I've been rethinking my "rethinking". That is, I now think the work on congruence closure is of secondary importance and can be deferred. I've implemented a simple cache for projection -- I have plans for a more elaborate one -- but it seems to be effective e.g. for the example in #31849. |
@nikomatsakis Is this still a problem today? |
This is still a thing today, although I've improved the situation in #48296 by reducing the complexity of recursion itself. |
This is still an issue and under the right circumstances is severe enough that it entirely blocks compilation of real-world code due to OOM. |
@syntacticsugarglider you may want to test with #90913. For me it fixes the reproducer in #74456 and a different performance issue I ran into. So it might help with other ones too. |
@the8472 thanks for the heads-up, gave that a try and it fixes the OOM but my test project I have sitting around (not the repro on that issue) still doesn't build, i gave it a core on my 4900HS for over an hour of CPU time to no avail. I'll do some profiling when I get a chance and play around with different repros, definitely possible it's a different issue. |
Both in trans and in typeck. Must be somewhat careful around type parameters and so forth. Probably we want to introduce a cache onto the fulfillment context to use for normalization as well.
The text was updated successfully, but these errors were encountered: