rokucommunity / vscode-brightscript-language

A Visual Studio Code extension for Roku's BrightScript language
MIT License
110 stars 41 forks source link

Extension causes high cpu load #230

Closed luis-soares-sky closed 4 years ago

luis-soares-sky commented 4 years ago

We're noticing consistently high processing times, and the process will keep running even after closing VS Code.

Screenshot 2020-05-04 at 18 26 42

TwitchBronBron commented 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.

TwitchBronBron commented 4 years ago

Sorry, forgot to mention which setting.

Set brightscript.enableLanguageServer to false to disable it completely.

TwitchBronBron commented 4 years ago

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.

image

I have the fix local, and will release it after a little bit more testing, hopefully sometime tonight.

TwitchBronBron commented 4 years ago

@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.

luis-soares-sky commented 4 years ago

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!

TwitchBronBron commented 4 years ago

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.