Closed luis-soares-sky closed 4 years ago
Thanks! This is very helpful. I'll try and dig into this to see if I can narrow down the cause of the issues.
In the mean time, if you are unable to work, you can disable the language server with a user/workspace setting. However, that will obviously remove any inline parse checking.
Sorry, forgot to mention which setting.
Set brightscript.enableLanguageServer
to false to disable it completely.
There is definitely a performance issue, introduced after 0.8.2. I ran a few benchmarks, and I think that I have some fixes. If my fixes didn't break anything else, then I have actually doubled the performance of the parser since 0.8.2.
I have the fix local, and will release it after a little bit more testing, hopefully sometime tonight.
@luis-soares-sky, extension version 2.1.14 includes these changes. Can you please try it again and see how it works for you? Also if you have a chance, compare 2.1.14's performance to 2.1.9 (the last release without the performance bugs) and see if it has improved at all.
I don't know how to take metrics like the ones you posted, but it's safe to say that I'm not getting hanging processes anymore, and overall the performance feels much better. Even more so than 2.1.9 which did feel a bit sluggish in comparison.
Thank you!
Good to hear! The metrics I posted were from a custom benchmark script I wrote just for this. I'm working on converting it into something that GitHub Actions can run on every pull request, so that way we can catch performance regressions before they get released. :) I'm going to close this issue, but please keep us informed if you notice any other performance issues.
We're noticing consistently high processing times, and the process will keep running even after closing VS Code.
Performance
brightscript
2.1.11
Darwin x64 18.7.0
1.44.2