100% CPU load with this extension

[ZenVoich]

When I'm working on mops VSCode loads the cpu at 100%.

Checked versions: 0.8.2 - 100% CPU load 0.7.4 - 100% CPU load 0.6.4 - works fine

[rvanasa]

Thanks for checking each of these extension versions. Does anything look out of place in the "Output" tab (after selecting "Motoko Language Server")?

[ZenVoich]

I see that it calls mops sources for each nested package that was created for testing) and some of them (which didn't run mops install) get these errors: All these commands are run every time when I open new motoko file or change motoko file, and loads CPU for 100% for ~13 seconds.

Some possible solutions that I see:

• In mops, I could remove all these 'testing packages' and replace them with script to generate packages and/or add e2e tests
• In mops, run mops install when mops sources is called
• In the extension, cache mops sources result based on mops.toml the md5 hash
• In the extension, cache the AST of the source files based on the md5 hash
• In the extension, add setting to exclude some paths

[rvanasa]

Gotcha. It looks like the extension is trying to automatically re-check for MOPS packages on file save, which was introduced as a way to fix various issues with users installing Vessel / MOPS without restarting the VS Code language server.

What's your opinion on running mops install upon calling mops sources? This is the default behavior for Vessel, so I originally built the integration around this assumption.

I could also add a setting to deactivate this retry-on-save behavior so that you can add it to your .vscode/settings.json file for this workspace.

In the extension, cache (mops sources result / AST) based on the md5 hash

As a side note, I've considered doing this, but it tends to cause subtle issues when updating packages to new versions (especially for Vessel, which relies heavily on fetching remote config files).

[ZenVoich]

What's your opinion on running mops install upon calling mops sources? This is the default behavior for Vessel, so I originally built the integration around this assumption.

Added running mops install upon calling mops sources in mops cli 0.6.4

[rvanasa]

Great; thanks! Does this fix the issue, or would it be helpful for me to also include the retry-on-save setting?

[ZenVoich]

Does this fix the issue

Unfortunately doesn't, but removing all my test packages helps, I will try to remove them in favor of generating packages for testing.

would it be helpful for me to also include the retry-on-save setting?

not sure if this will help

[rvanasa]

Looking at the implementation, the extension ignores directories starting with a . (e.g. test/.projects/...). This appears to work as a temporary fix in my local mops repository. I'll also open a PR to include some additional caching for commands such as mops sources.

[rvanasa]

I found some additional ways to improve performance in #171 and #172; let me know if this ends up helping.

[ZenVoich]

I can see that it only uses CPU on startup, not every time a file is opened or modified. Also I prefixed the test folders with . and that worked well too. Thank you

[rvanasa]

Glad to hear. Closing for now, and happy to reopen if needed.