Skip to content

Refactor LSP: Centralize Workspace-Level Resources #7111

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

Open
JoshuaBatty opened this issue Apr 24, 2025 · 0 comments
Open

Refactor LSP: Centralize Workspace-Level Resources #7111

JoshuaBatty opened this issue Apr 24, 2025 · 0 comments
Assignees
Labels
big this task is hard and will take a while language server LSP server performance Everything related to performance, speed wise or memory wise. team:tooling Tooling Team

Comments

@JoshuaBatty
Copy link
Member

Currently, sway-lsp creates separate sessions with duplicated state (like Engines and TokenMap) for each member within a workspace, leading to inefficiency. This issue tracks the effort to refactor the language server to properly handle Sway workspaces by leveraging the existing workspace support within forc-pkg.

Resources like token_map, engines, diagnostics, runnables, and build_plan_cache should be moved from existing within uniqe Session instances per workspace member, into the main ServerState so they can be shared amongst all workspace members. This refactoring will significantly improve performance and reduce memory usage for workspace users and will be implemented incrementally across several pull requests.

@JoshuaBatty JoshuaBatty added language server LSP server big this task is hard and will take a while performance Everything related to performance, speed wise or memory wise. labels Apr 24, 2025
@JoshuaBatty JoshuaBatty self-assigned this Apr 24, 2025
@JoshuaBatty JoshuaBatty added the team:tooling Tooling Team label Apr 24, 2025
JoshuaBatty added a commit that referenced this issue May 19, 2025
## Description
* Moves `SyncWorkspace` ownership from individual `Session` instances to
a single, global instance within `ServerState`.
* `SyncWorkspace` is now initialized once when the LSP server starts,
creating a single temporary workspace clone.

Also removes the `resync` function. This was causing the server and the
IDE to fall out of sync with each other. For example, if you have 2
panels open and then save a file in one of the tabs but have unsaved
changes in the other tab then those changes would not be reflected in
the temp memory folder. This meant everything would be out of sync. We
already are syncing everything on each keystroke per file so this fn was
not necessary in the first place.

This PR is a precursor to #7139
part of #7111

## Checklist

- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.

---------

Co-authored-by: zees-dev <[email protected]>
JoshuaBatty added a commit that referenced this issue May 20, 2025
## Description
This PR moves `TokenMap` and `Engines` out of the `Session` type up to
`ServerState` so a single instance of each can be shared across all
workspace members.

Up until now, each workspace member used a unique `Engines`. This meant
the standard library and any other dependancies were unable to utilise
the `QueryEngine` cache, leading to lots of duplicate entries. This was
leading to inflated initialization times when opening a new workspace
member and significantly increasing the RAM footprint of the language
server.

For example, opening each workspace member in the FUSD projects
workspace would see RAM usage exceeding ~30.0 gig. Now we no longer
exceed 2.0 gig of RAM.

Future PR's will move the `BuildPlanCache` up to the `ServerState` level
as well.

part of #7111 & #6226
closes #5645
closes #5856

## Checklist

- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.

---------

Co-authored-by: kaya <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big this task is hard and will take a while language server LSP server performance Everything related to performance, speed wise or memory wise. team:tooling Tooling Team
Projects
None yet
Development

No branches or pull requests

1 participant