100% CPU load with this extension about vscode-motoko HOT 10 CLOSED

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.

from vscode-motoko.

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

from vscode-motoko.

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

from vscode-motoko.

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

from vscode-motoko.

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

from vscode-motoko.

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

from vscode-motoko.

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

from vscode-motoko.

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

from vscode-motoko.

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

from vscode-motoko.

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

from vscode-motoko.