Skip to content
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

Slow plugin #172

Open
PaulZhemanov opened this issue Mar 25, 2024 · 24 comments
Open

Slow plugin #172

PaulZhemanov opened this issue Mar 25, 2024 · 24 comments
Assignees

Comments

@PaulZhemanov
Copy link

Hi guys! I'm having trouble getting the plugin to work correctly. It works so slowly. I need correct autocomplete, go to definition, hinting of function signature and arguments. Help me please.

forc-lsp 0.49.3
@JoshuaBatty
Copy link
Member

Hi Paul, I'm happy to look into this for you. Do you have a specific project I might be able to reproduce with?

@PaulZhemanov
Copy link
Author

PaulZhemanov commented Mar 26, 2024

Hi Paul, I'm happy to look into this for you. Do you have a specific project I might be able to reproduce with?

Hi! Can you send telegram nickname?

@PaulZhemanov
Copy link
Author

Hi Paul, I'm happy to look into this for you. Do you have a specific project I might be able to reproduce with?

Hi! Can you send telegram nickname?

@JoshuaBatty

@chlenc
Copy link

chlenc commented Mar 27, 2024

@JoshuaBatty
Copy link
Member

Received thanks guys. I'll start doing some profiling over the next week.

@PaulZhemanov
Copy link
Author

Received thanks guys. I'll start doing some profiling over the next week.

@JoshuaBatty this "loading" appears very often and hinders development,
image

@PaulZhemanov
Copy link
Author

@JoshuaBatty Hello. The plugin is terrible.. I compile my contract with no errors and see this in my editor...
IMAGE 2024-04-01 21:12:56
A plugin should speed up development, not slow it down. Please fix it.

@JoshuaBatty
Copy link
Member

JoshuaBatty commented Apr 2, 2024

Hi @PaulZhemanov please know we are aware of the issue and that we are working on this as a priority. We will hopefully have a fix soon. The TLDR of the issue is the compiler is crashing due to the garbage collector not working properly for certain types. When this happens it also crashed the server plugin, leading to the screenshots. Reloading the window will allow it to work again until the next time the GC <> compiler become out of sync. Obviously this is very frustrating for users and we are looking into a fix.

@JoshuaBatty
Copy link
Member

If you want a quick fix you could checkout my josh/storage_gc_test branch on the sway repo and change this line from true to false gc_enabled: false,

then run cargo install --path ./forc-plugins/forc-lsp to install a local copy of the language server. Because the garbage collector is disabled you'll probably want to reload the editor when the RAM usage gets too high but it should at least get rid of the crash for now while we investigate the root cause.

@JoshuaBatty
Copy link
Member

Hey @chlenc & @PaulZhemanov we have fixed the Garbage collector and LSP issues. This has been merged and is in the latest 0.54 release. It's still going to be slow to respond due to the lack of granular caching and the size of your workspace, but it shouldn't be crashing and become non-responsive now. We're now looking at further optimisations.

@chlenc
Copy link

chlenc commented Apr 22, 2024

gm guys thank you!!

Btw is it possible to somehow disable reentrancy warnings?

@chlenc
Copy link

chlenc commented Apr 22, 2024

image

@chlenc
Copy link

chlenc commented Apr 25, 2024

@JoshuaBatty

@JoshuaBatty
Copy link
Member

Sorry i've been out sick this week. We don't off the ability to disable certain warning types but we could look at adding that in the future. I'll take a closer look at this next week and see what we might be able to do.

@PaulZhemanov
Copy link
Author

Hi @JoshuaBatty . I got this notification and plugin doesnt work.
image

@PaulZhemanov
Copy link
Author

PaulZhemanov commented May 3, 2024

Hi @JoshuaBatty . how can I disable these settings

If you want a quick fix you could checkout my josh/storage_gc_test branch on the sway repo and change this line from true to false gc_enabled: false,

then run cargo install --path ./forc-plugins/forc-lsp to install a local copy of the language server. Because the garbage collector is disabled you'll probably want to reload the editor when the RAM usage gets too high but it should at least get rid of the crash for now while we investigate the root cause.

@JoshuaBatty
Copy link
Member

Hi Paul what version of forc-lsp are you using?

The garbage collection issue has been resolved and is in the latest release.

@mpoplavkov
Copy link

Hey @chlenc & @PaulZhemanov we have fixed the Garbage collector and LSP issues. This has been merged and is in the latest 0.54 release. It's still going to be slow to respond due to the lack of granular caching and the size of your workspace, but it shouldn't be crashing and become non-responsive now. We're now looking at further optimisations.

Hey @JoshuaBatty, how to update forc-lsp to 0.54 if I'm using the beta-5 channel?

@PaulZhemanov
Copy link
Author

@JoshuaBatty forc-lsp 0.49.3

@JoshuaBatty
Copy link
Member

JoshuaBatty commented May 7, 2024

I would suggest the quickest way to get it working would be to checkout the sway repo and follow the below commands to get the server updated.

git checkout https://github.com/FuelLabs/sway
cd sway
cargo install --path ./forc-plugins/forc-lsp

then running the which forc-lsp you should see something like.

 ~  which forc-lsp                                                                                           
/Users/joshuabatty/.cargo/bin/forc-lsp

 ~  forc-lsp --version                                                                                  
forc-lsp 0.56.0

@chlenc
Copy link

chlenc commented May 7, 2024

image

hope plugin will be better soon

@chlenc
Copy link

chlenc commented May 9, 2024

Gm guys

@JoshuaBatty @arboleya

Are there any updates??

@JoshuaBatty
Copy link
Member

The main issue here is that our compiler is slow and we lack a caching system to support more incremental compilation. We are focusing on improving compilation speeds at the moment, in-fact we have merged 3 PR's in the past 24 hours that have improved compilation speeds by ~60%. We are also in the process of putting together a design for implementing more granular caching. Unfortunately, until the compiler is optimised and caching support is implemented then the language server performance is going to be sluggish on large projects like the spark repo. I'll keep you updated as we go.

JoshuaBatty added a commit to FuelLabs/sway that referenced this issue Aug 15, 2024
## Description
This PR implements a typed module caching system for the compiler when
interacted with from the language server. The main goal is to improve
performance by caching typed modules and reusing them when possible,
reducing unnecessary recompilation.

## Key Changes
- Introduced `CowCache` for efficient, thread-safe caching with
copy-on-write semantics
- Implemented typed module caching in the `QueryEngine`
- Updated `ServerState` and `Session` to utilize the new caching system


## Performance Improvements
These changes show promising performance improvements in processing
didChange events, particularly for larger projects. Here are some
benchmarks using the FUSD libraries Sway project (19 Sway files):

| Build | Before | After | Improvement |
|-------|--------|-------|-------------|
| Debug | 448.25ms | 123.73ms | 72.4% faster |
| Release | 103.83ms | 53.59ms | 48.4% faster |

These improvements should lead to a more responsive development
experience, especially when making frequent small changes.

closes #6228
improves: FuelLabs/sway-vscode-plugin#172

## Checklist

- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] 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.
@JoshuaBatty
Copy link
Member

Another update, we now have support for caching at the file level rather than the previous project level. This should speed up response times substantially for projects with lots of files. We have plans to enable caching at the AST node level but this should be a nice bridge in the meantime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants