Closed ghost closed 3 years ago
nickspoons
commented
3 years ago It's the server. OmniSharp-roslyn analyses the entire solution, and so it can take a while for that to quiet down, especially if you have a very large solution.
If you do something like opening a .cs file in your ~/home directory, then the server thinks your entire home is the project and will analyse all .cs files in all sub folders. Could that be the issue here? You're pretty light on details.
ghost
commented
3 years ago I don't have any subdirectories. If it had been still analysing, I expect that there would have been more requests to the server in the logs, but I don't see them.
ghost
commented
3 years ago :OmniSharpStopAllServers has the effect of reducing the usage while I'm not using vim, which is what I'm looking for, but I just wanted to try to find why this should even be necessary.
nickspoons
commented
3 years ago We're not sending requests to the server, but the server still does work on it's own, and it sends its findings back to the client even though we haven't asked for them, in the form of diagnostic messages and info about files that have been analysed.
This is the same server that is used by other editors like vscode, which displays e.g. diagnostic counts in the sidebar beside files that haven't yet been opened. So it does things we don't necessarily need in vim.
However this startup process normally only takes a few seconds and then CPU/memory goes right down. If it continues to be high, then that sounds like it is analysing much more than a single file. How are you opening the file? Can you share the log? The first few lines of the log show you which project/solution is being started by the server. If you add let g:OmniSharp_loglevel = 'debug' to your .vimrc then the exact command used to launch the server is also written to the log.
nickspoons
commented
3 years ago If you want more logging detail, but don't want to see all the raw JSON that is passed between client and server (which can be a lot, when buffer contents are being updated and semantic highlights are being requested), use let g:OmniSharp_loglevel = 'DEBUG' instead
ghost
commented
3 years ago nickspoons
commented
3 years ago That all looks fine, although the timings seem unreasonably slow - do they speed up faster than ~4s after the server has warmed up?
This all looks to be server-side. You can try running the command from your log directly in the terminal and see if it uses the same amount of CPU outside of Vim:
/Users/alexi/.cache/omnisharp-vim/omnisharp-roslyn/run -s /Users/alexi/.vim/plugged/vimspector/support/test/csharp/csharp.sln -l DEBUG -e utf-8I followed the instructions to install ALE. If I remove it from my .vimrc, the problem goes away.
Should I need so many plugins for this? I have coc.nvim and omnisharp-vim installed, is it normal to have to need additional plugins for diagnostics information?
ghost
commented
3 years ago :OmniSharpGlobalCodeCheck causes the usage to go back up again and stay there independently of ALE.
nickspoons
commented
3 years ago Using OmniSharp-vim with ALE is normal, that's what I do. I suspect what is happening is that once either ALE or :OmniSharpGlobalCodeCheck requests diagnostics, that triggers the server to start analysing. But it's not usual for the server to keep using so much CPU, and I tested myself on that vimspector test project from your log and it doesn't happen for me.
It would be worth testing with a minimal config, just OmniSharp-vim and ALE and no other plugins. But it seems like it's an issue with OmniSharp-roslyn.
Does the CPU go down after leaving it for a while? Perhaps test loading vim in that test project and then just leave it for 5-10 minutes and see if it quietens down? Again, this is not normal, I'm just trying to understand what you're experiencing.
What is your environment? You haven't described it at all but the log mentions "macOS version - arm64". Perhaps ARM is not supported by OmniSharp-roslyn?
ghost
commented
3 years ago Thanks for the suggestion. I have been using the homebrew built version of vim.
If I use the one built by Apple, the usage is normal.
nickspoons
commented
3 years ago Oh that's good to hear - and very interesting. Would you mind posting the output of :version of both the brew version and the apple version? That might make it easier for others to track down similar issues in the future.
ghost
commented
3 years ago alexi@workstation ~ % vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 21 2021 10:39:53)
macOS version - arm64
Included patches: 1-3550
Compiled by Homebrew
Huge version without GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm -tcl
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
-balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +gettext +num64 +textobjects
-browse -hangul_input +packages +textprop
++builtin_terms +iconv +path_extra +timers
+byte_offset +insert_expand +perl +title
+channel +ipv6 +persistent_undo -toolbar
+cindent +job +popupwin +user_commands
-clientserver +jumplist +postscript +vartabs
+clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +virtualedit
+cmdline_hist +langmap -python +visual
+cmdline_info +libcall +python3 +visualextra
+comments +linebreak +quickfix +viminfo
+conceal +lispindent +reltime +vreplace
+cryptv +listcmds +rightleft +wildignore
+cscope +localmap +ruby +wildmenu
+cursorbind +lua +scrollbind +windows
+cursorshape +menu +signs +writebackup
+dialog_con +mksession +smartindent -X11
+diff +modify_fname -sodium -xfontset
+digraphs +mouse -sound -xim
-dnd -mouseshape +spell -xpm
-ebcdic +mouse_dec +startuptime -xsmp
+emacs_tags -mouse_gpm +statusline -xterm_clipboard
+eval -mouse_jsbterm -sun_workshop -xterm_save
+ex_extra +mouse_netterm +syntax
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -tag_old_static
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/opt/homebrew/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X -DMACOS_X_DARWIN -g -O2 -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang -L. -fstack-protector-strong -L/opt/homebrew/lib -L/opt/homebrew/opt/libyaml/lib -L/opt/homebrew/opt/openssl@1.1/lib -L/opt/homebrew/opt/readline/lib -o vim -lm -lncurses -liconv -lintl -framework AppKit -L/opt/homebrew/opt/lua/lib -llua5.4 -mmacosx-version-min=11.3 -fstack-protector-strong -L/opt/homebrew/Cellar/perl/5.34.0/lib/perl5/5.34.0/darwin-thread-multi-2level/CORE -lperl -L/opt/homebrew/opt/python@3.9/Frameworks/Python.framework/Versions/3.9/lib/python3.9/config-3.9-darwin -lpython3.9 -framework CoreFoundation -lruby.3.0 -L/opt/homebrew/Cellar/ruby/3.0.2_1/lib alexi@workstation ~ % /usr/bin/vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 28 2021 06:52:20)
macOS version
Included patches: 1-2029
Compiled by root@apple.com
Normal version without GUI. Features included (+) or not (-):
+acl -farsi +mouse_sgr +tag_binary
-arabic +file_in_path -mouse_sysmouse -tag_old_static
+autocmd +find_in_path -mouse_urxvt -tag_any_white
+autochdir +float +mouse_xterm -tcl
-autoservername +folding +multi_byte -termguicolors
-balloon_eval -footer +multi_lang +terminal
-balloon_eval_term +fork() -mzscheme +terminfo
-browse -gettext +netbeans_intg +termresponse
+builtin_terms -hangul_input +num64 +textobjects
+byte_offset +iconv +packages +textprop
+channel +insert_expand +path_extra +timers
+cindent -ipv6 -perl +title
-clientserver +job +persistent_undo -toolbar
+clipboard +jumplist +popupwin +user_commands
+cmdline_compl -keymap +postscript -vartabs
+cmdline_hist +lambda +printer +vertsplit
+cmdline_info -langmap -profile +virtualedit
+comments +libcall +python/dyn +visual
-conceal +linebreak -python3 +visualextra
+cryptv +lispindent +quickfix +viminfo
+cscope +listcmds +reltime +vreplace
+cursorbind +localmap -rightleft +wildignore
+cursorshape -lua +ruby/dyn +wildmenu
+dialog_con +menu +scrollbind +windows
+diff +mksession +signs +writebackup
+digraphs +modify_fname +smartindent -X11
-dnd +mouse -sound -xfontset
-ebcdic -mouseshape +spell -xim
-emacs_tags -mouse_dec +startuptime -xpm
+eval -mouse_gpm +statusline -xsmp
+ex_extra -mouse_jsbterm -sun_workshop -xterm_clipboard
+extra_search -mouse_netterm +syntax -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X_UNIX -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L/usr/local/lib -o vim -lm -lncurses -liconv -framework Cocoa Thanks
After the plugin finishes analysing the one buffer that I have open in vim, should it be normal that my terminal steadily continues to use 25% cpu?
I checked
:OmniSharpOpenLog, and it appears to have only requested /updatebuffer and then /highlight once.I tried to profile also, I don't really understand the output but if it's helpful:
There seems to be something continuing working in the background. If I kill the mono process, the usage drops to somewhere around one or two percent, which is where I would like it to be if I don't happen to be doing anything that would trigger a request to the language server.