-
Notifications
You must be signed in to change notification settings - Fork 26.2k
fix(compiler): cache external reference resolution #21359
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
Conversation
You can preview c838585 at https://pr21359-c838585.ngbuilds.io/. |
You can preview cf2ebde at https://pr21359-cf2ebde.ngbuilds.io/. |
You can preview 8d9db53 at https://pr21359-8d9db53.ngbuilds.io/. |
Cache reference resolution for external references as finding the declaration of a symbol is expensive and does not change for a program once created. This resolves a signficant performance regression in the langauge service.
You can preview f78c6bc at https://pr21359-f78c6bc.ngbuilds.io/. |
@chuckjaz it appears to break google3: http://test/OCL:181231159:BASE:181372032:1515535948074:d778aed |
The failure a flaky test. |
Cache reference resolution for external references as finding the declaration of a symbol is expensive and does not change for a program once created. This resolves a signficant performance regression in the langauge service. PR Close #21359
Cache reference resolution for external references as finding the declaration of a symbol is expensive and does not change for a program once created. This resolves a signficant performance regression in the langauge service. PR Close angular#21359
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Cache reference resolution for external references as finding
the declaration of a symbol is expensive and does not change
for a program once created. This resolves a signficant performance
regression in the langauge service.
PR Type
What kind of change does this PR introduce?
What is the current behavior?
The language service will often take up to 600ms to handle a request, such as hover or completions, it used to take under 100ms in v4.0
What is the new behavior?
The language service now takes roughly what it used to take in v4.0.
Does this PR introduce a breaking change?