-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Rethink our VFS abstraction #18948
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
Comments
cc @davidbarsky opening this so we can keep track of it (might want to link to this from the perf tracking issue even) |
Unless I misunderstood what you said, we can lazily load files and file contents in Salsa today. Regardless, my opinion is that we should try to batch IO as much as possible instead of being lazy.
Yeah, I'll update that issue to include this. |
Is #15836 also related? |
Yes, probably. |
A note about source roots from our usage in ELP, which is based on RA. We recently updated the project model to match internal buck2 targets. These generate a test target per test file, and each can have different config, which we store in |
The current setup is brittle and tends to break very easily in unexpected ways (#18886 (comment) being an example). The system is also somewhat difficult to follow (the way we partition the VFS into sourceroots is not easily understandable). We should simplify this and clean it up. One idea we've had is to first and foremost move the VFS state into salsa (once we have migrated over to the new one), as currently we have a weird middle ground between the two (some info is outside salsa, some is inside). The other thing is that we need to likely add support for lazily loading file contents (which likely means incurring i/o within salsa queries).
The text was updated successfully, but these errors were encountered: