-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[ty] Remove ScopedExpressionId
#19019
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
|
Woah those report diffs are amazing. |
That's @ibraheemdev's work. He deserves a shoutout in tomorrow's meeting but Notion is having a bad day :( |
CodSpeed Instrumentation Performance ReportMerging #19019 will improve performances by 4.59%Comparing Summary
Benchmarks breakdown
|
CodSpeed WallTime Performance ReportMerging #19019 will improve performances by 7.79%Comparing Summary
Benchmarks breakdown
|
HasScopedExpressionId
ScopedExpressionId
This PR makes me wonder if we should try to split our semantic index incrementally (scope by scope). This won't help much for first party modules where we need all scopes but it can reduce the amount of data that we collect for third party modules AND it could maybe even replaces |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great — less code and a clear performance win!
Summary
The motivation of
ScopedExpressionId
was that we have an expression identifier that's local to a scope and, therefore, unlikely to change if a user makes changes in another scope. A local identifier like this has the advantage that query results may remain unchanged even if other parts of the file change, which in turn allows Salsa to short-circuit dependent queries.However, I noticed that we aren't using
ScopedExpressionId
in a place where it's important that the identifier is local. It's main use is insideinfer
which we always run for the entire file. The one exception to this isUnpack
but unpack runs as part ofinfer
.Edit: The above isn't entirely correct. We used ScopedExpressionId in TypeInference which is a query result. Now using ExpressionNodeKey does mean that a change to the AST invalidates most if not all TypeInference results of a single file. Salsa then has to run all dependent queries to see if they're affected by this change even if the change was local to another scope.
If this locality proves to be important I suggest that we create two queries on top of TypeInference: one that returns the expression map which is mainly used in the linter and type inference and a second that returns all remaining fields. This should give us a similar optimization at a much lower cost
I also considered remove
ScopedUseId
but I believe that one is still useful because usingExpressionNodeKey
for it instead would mean that allUseDefMap
change when a single AST node changes. Whether this is important is something difficult to assess. I'm simply not familiar enough with theUseDefMap
. If the locality doesn't matter for theUseDefMap
, then a similar change could be made andbindings_by_use
could be changed to anFxHashMap<UseId, Bindings>
whereUseId
is a thin wrapper aroundNodeKey
.Closes astral-sh/ty#721