22 processes of 70-250mb each for only 4 tabs of code (totaling 150 lines, with no macros, 2 templates)
I only noticed because vscode and chrome kept running out of memory and crashing (on my older 4790k 16gb computer)
Usually the idea is that you have one instance per project file (i.e. a file which is passed to the Nim compiler for compilation).
Correct but I've never seen this done properly by any editor plugin. No idea why everybody gets it this wrong...
If you're not in this condition you may experience:
I've tested most of the combinations available and I prefer nimlsp instead of nimlangserver as it bundles nimsuggest and doesn't have to deal with nimsuggest external process management
sadly nimlsp is a second class citizen and I don't remember which vscode extension run it, but if you want to try another editor I can suggest Zed + official Nim extension + nimlsp, so far the best combination I've found (vim experience is also very good)
The older VScode plugins did it right once you set up a project file which is pretty trivial to do, so I guess that's why there never was that much of a need to implement guessing.
Same goes for the official language server, but it insists on guessing itself once in a nimble project which seems to be bugged in a really weird way I never managed to understand, hence I did not report a bug yet. It could be related to: https://github.com/nim-lang/langserver/issues/303 or https://github.com/nim-lang/langserver/issues/326 and mentioned race condition in the langserver code.
This is why I still use Saem's extension as its the most stable once a project file is given.
Yeah, nimlangserver has this strange behaviour: when you have more than one file/project open it starts creating a lot of nimsuggest processes.
To "fix" this, was introduced a setting maxNimsuggestProcesses. I have it set to 3 in my neovim plugin config. And indeed nimlangserver does respect it and I haven't seen it hog memory since. It still, sometimes, refuses to respond, occasionally crashes or shows outdated diagnostics, but quick :LspRestart fixes it in 99% cases.
I'm not familiar with VSCode, but you should be able to configure nimlangserver there as well.
What I ended up doing when I tried nimlsp (using Fish shell):
while sleep 5; pgrep -x nimsuggest | xargs -I{} choom -n 1000 -p {}; end
# in another session
watch -t --exec fish -c 'ps -o pid,user,vsize,comm --no-headers -U $USER | while read -l pid user vsize comm; echo $pid (cat /proc/$pid/oom_score) $vsize $comm; end | sort -k2 -nr | head -10'I've experienced the "zombie army of nimsuggest processes" issue in the past, and I've found out that the issue was not nimlangserver or vscode, but choosenim shims that fails to forward the kill signal down to the real process
I've stopped using choosenim after I found this, and it's not happening anymore (all nimsuggest processes close when I close vscode). I now just have a non zombie army of nimsuggest processes
Can you elaborate more about stopping using choosenim?
Did you delete it?
I have it but only used it once to update nim
Quick correction, the 250 mb process was windsurf/codium plugin for vscode
However the processes all spawn within 2 minutes of lauching the project
Having the lib.nim (~130 lines) spawned ~6 processes. Opening main,test,bench files (each maybe 10 lines) reached the 22 processes. Closing them and keeping the lib.nim still kept all processes
I download nim binaries from the website into something like ~/nim/toolchains/nim-2.2.2 and then I have a symlink of it in ~/nim/toolchains/current
then I have ~/nim/toolchains/current/bin in PATH
I change symlink whenever I need to change nim version
Correct but I've never seen this done properly by any editor plugin. No idea why everybody gets it this wrong...
We talked about this already, the known command is broken. Thats why it keeps spawning processes as a fallback. The new default is one max ns process, so even when known would return false or timeout, it tries to reuse the instance. That said, in the latest sources which is about to be released, there a few bugs fixed related to process handling
Thanks! That fixed it
Now the project of 4 tabs starts 8 processes, which settle to 4 after a few minutes