Omnisharp takes excessive time and memory usage when fired from Omnisharp-vim #558

Craige · 2020-02-19T01:52:16Z

On the same project/solution, Omnisharp takes several minutes longer starting up when used under Omnisharp.vim as opposed to the same project opened in VSCode. Memory usage is also ~double the memory usage of the OmniSharp server under VSCode, and CPU usage spikes for a lengthy amount of time as well.

I'm not sure what the differences are between how VSCode uses the OmniSharp server and how OmniSharp.vim uses it, but there is clearly something significantly different causing significantly worse performance. This becomes more noticeable on large solutions/projects.

nickspoons · 2020-02-19T01:56:01Z

Please share your .vimrc and give some description of your environment

Craige · 2020-02-19T02:07:10Z

MacOS 10.14.6.
OmniSharp server has Roslynator analyzers enabled via ~/.omnisharp/omnisharp.json (Haven't really tested without)
Was opening OrchardCore.ContentFields project. VSCode instance settled to around 600-700MB. OrhardCore.vim instance settled at ~1.26GB and took much longer to get there, which much higher CPU usage.
DotnetCore 3.1 (Don't think that matters as OmniSharp is bundled with its own mono on MacOS)

The OmnSharp stuff:

" OMNISHARP
"" Use the stdio OmniSharp-roslyn server
let g:OmniSharp_server_stdio = 1

" let g:OmniSharp_start_without_solution = 1

" Set the type lookup function to use the preview window instead of echoing it
"let g:OmniSharp_typeLookupInPreview = 1

" Timeout in seconds to wait for a response from the server
let g:OmniSharp_timeout = 5
" much simpler "server is ready" detection mechanism (and doesn't work well for large solutions):
" https://github.com/OmniSharp/omnisharp-vim/issues/507#issuecomment-526945899
let g:OmniSharp_server_stdio_quickload = 1

" Don't autoselect first omnicomplete option, show options even if there is only
" one (so the preview documentation is accessible). Remove 'preview' if you
" don't want to see any documentation whatsoever.
set completeopt=longest,menuone,preview

" Fetch full documentation during omnicomplete requests.
" By default, only Type/Method signatures are fetched. Full documentation can
" still be fetched when you need it with the :OmniSharpDocumentation command.
"let g:omnicomplete_fetch_full_documentation = 1

" Set desired preview window height for viewing documentation.
" You might also want to look at the echodoc plugin.
set previewheight=5

" Tell ALE to use OmniSharp for linting C# files, and no other linters.
let g:ale_linters = { 'cs': ['OmniSharp'] }

" Update semantic highlighting after all text changes
" let g:OmniSharp_highlight_types = 3
" Update semantic highlighting on BufEnter and InsertLeave
let g:OmniSharp_highlight_types = 2

augroup omnisharp_commands
    autocmd!

    " Show type information automatically when the cursor stops moving
    autocmd CursorHold *.cs call OmniSharp#TypeLookupWithoutDocumentation()

    " The following commands are contextual, based on the cursor position.
    autocmd FileType cs nnoremap <buffer> gd :OmniSharpGotoDefinition<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>fi :OmniSharpFindImplementations<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>fs :OmniSharpFindSymbol<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>fu :OmniSharpFindUsages<CR>

    " Finds members in the current buffer
    autocmd FileType cs nnoremap <buffer> <Leader>fm :OmniSharpFindMembers<CR>

    autocmd FileType cs nnoremap <buffer> <Leader>fx :OmniSharpFixUsings<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>tt :OmniSharpTypeLookup<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>dc :OmniSharpDocumentation<CR>
    autocmd FileType cs nnoremap <buffer> <C-\> :OmniSharpSignatureHelp<CR>
    autocmd FileType cs inoremap <buffer> <C-\> <C-o>:OmniSharpSignatureHelp<CR>

    " Navigate up and down by method/property/field
    autocmd FileType cs nnoremap <buffer> <C-k> :OmniSharpNavigateUp<CR>
    autocmd FileType cs nnoremap <buffer> <C-j> :OmniSharpNavigateDown<CR>

    " Find all code errors/warnings for the current solution and populate the quickfix window
    autocmd FileType cs nnoremap <buffer> <Leader>cc :OmniSharpGlobalCodeCheck<CR>
augroup END

" Contextual code actions (uses fzf, CtrlP or unite.vim when available)
nnoremap <Leader><Space> :OmniSharpGetCodeActions<CR>
" Run code actions with text selected in visual mode to extract method
xnoremap <Leader><Space> :call OmniSharp#GetCodeActions('visual')<CR>

" Rename with dialog
nnoremap <Leader>nm :OmniSharpRename<CR>
nnoremap <F2> :OmniSharpRename<CR>
" Rename without dialog - with cursor on the symbol to rename: `:Rename newname`
command! -nargs=1 Rename :call OmniSharp#RenameTo("<args>")

nnoremap <Leader>cf :OmniSharpCodeFormat<CR>

" Start the omnisharp server for the current solution
"nnoremap <Leader>ss :OmniSharpStartServer<CR>
"nnoremap <Leader>sp :OmniSharpStopServer<CR>

" Enable snippet completion
let g:OmniSharp_want_snippet=1

The full .vimrc, in case it matters. It's a bit of a mess lately....

filetype plugin on
filetype indent plugin on
syntax enable

set mouse=a
set hidden " Can switch buffers without saving

" show existing tab with 4 spaces width
set tabstop=4
" when indenting with '>', use 4 spaces width
set shiftwidth=4
" On pressing tab, insert 4 spaces
set expandtab

set cindent
set autoindent

set foldenable
set foldmethod=syntax

set colorcolumn=80
set relativenumber
set number
set ruler " Always show current positions along the bottom
set laststatus=2 " always show the status line
set nowrap " do not wrap line
set scrolloff=5 " Keep 10 lines (top/bottom) for scope
set vb t_vb= " don't blink
set cursorline
set nocursorcolumn
set completeopt=longest,menuone "don't insert first result in omnicomplete
set exrc
set clipboard=unnamed
set spelllang=en_us
set ignorecase

" Show whitespace
set list
set listchars=tab:>-,trail:~,extends:>,precedes:<,space:·

set showbreak=…

let g:netrw_liststyle=3

colorscheme distinguished

set statusline=%<%f\ %h%m%r%=%-14.(%l,%c%V%)\ %P\ %{winnr()} " add winnumber to end of status bar

command! -bang -nargs=* -complete=file Make AsyncRun -program=make @ <args>

" php-namespace bindings
inoremap <Leader>u <C-O>:call PhpInsertUse()<CR>
noremap <Leader>u :call PhpInsertUse()<CR>


" Preceed commit message with pivotal id in git commit
let @g = 'jjj$vbyggi[#]�"0P�$'

" enable line numbering in netrw
let g:netrw_bufsettings="noma nomod nonu nobl nowrap ro rnu"

"inoremap <Leader>to :tabnew<CR>
execute pathogen#infect()


" Utilisnips settings/binding
let g:UltiSnipsExpandTrigger="<c-e>"
let g:UltiSnipsJumpForwardTrigger="<c-b>"
let g:UltiSnipsJumpBackwardTrigger="<c-z>"


inoremap <expr> <Tab>   pumvisible() ? "\<C-n>" : "\<Tab>"
inoremap <expr> <S-Tab> pumvisible() ? "\<C-p>" : "\<S-Tab>"
inoremap <expr> <cr>    pumvisible() ? "\<C-y>" : "\<cr>"
imap <c-space> <Plug>(asyncomplete_force_refresh)

if has('python3')
    " let g:UltiSnipsExpandTrigger="<c-e>"
    call asyncomplete#register_source(asyncomplete#sources#ultisnips#get_source_options({
        \ 'name': 'ultisnips',
        \ 'whitelist': ['*'],
        \ 'completor': function('asyncomplete#sources#ultisnips#completor'),
        \ }))
endif

nmap <Leader>w :w!<CR>
nmap <Leader>rd :redraw!<CR>
nmap <Leader>tn :tabnext<CR>
nmap <Leader>tp :tabprevious<CR>
nmap <Leader>tc <C-w>n<C-w>T
nmap <Leader>to <C-w>^<C-w>T
nmap <Leader>cs :let @+ = expand("%") . ":" . line(".")<CR>
vnoremap <Leader>cs :let @+ = expand("%") . ":" . line("v") . "-" . line(".")<CR>
nmap <Leader>sp :setlocal spell!<CR>
nmap <Leader>hl :set hlsearch!<CR>


map <C-Down> <c-w>j
map <C-Up> <c-w>k
map <C-Right> <c-w>l
map <C-Left> <c-w>h

" enable display-line navigation
"vmap j gj
"vmap k gk
"vmap $ g$
"vmap ^ g^
"vmap 0 g0
"nmap j gj
"nmap k gk
"nmap $ g$
"nmap ^ g^
"nmap 0 g0

" Turn on line wrapping with :Wrap
" Turn off relative line numbers as they're not accurate with the above line
" navigation mappings and wrapped lines
command! -nargs=* Wrap set wrap! linebreak nolist relativenumber!

" Create directory when saving file if it destination doesn't exist
augroup BWCCreateDir
    au!
    autocmd BufWritePre * if expand("<afile>")!~#'^\w\+:/' && !isdirectory(expand("%:h")) | execute "silent! !mkdir -p ".shellescape(expand('%:h'), 1) | redraw! | endif
augroup END

" OMNISHARP
"" Use the stdio OmniSharp-roslyn server
let g:OmniSharp_server_stdio = 1

" let g:OmniSharp_start_without_solution = 1

" Set the type lookup function to use the preview window instead of echoing it
"let g:OmniSharp_typeLookupInPreview = 1

" Timeout in seconds to wait for a response from the server
let g:OmniSharp_timeout = 5
" much simpler "server is ready" detection mechanism (and doesn't work well for large solutions):
" https://github.com/OmniSharp/omnisharp-vim/issues/507#issuecomment-526945899
let g:OmniSharp_server_stdio_quickload = 1

" Don't autoselect first omnicomplete option, show options even if there is only
" one (so the preview documentation is accessible). Remove 'preview' if you
" don't want to see any documentation whatsoever.
set completeopt=longest,menuone,preview

" Fetch full documentation during omnicomplete requests.
" By default, only Type/Method signatures are fetched. Full documentation can
" still be fetched when you need it with the :OmniSharpDocumentation command.
"let g:omnicomplete_fetch_full_documentation = 1

" Set desired preview window height for viewing documentation.
" You might also want to look at the echodoc plugin.
set previewheight=5

" Tell ALE to use OmniSharp for linting C# files, and no other linters.
let g:ale_linters = { 'cs': ['OmniSharp'] }

" Update semantic highlighting after all text changes
" let g:OmniSharp_highlight_types = 3
" Update semantic highlighting on BufEnter and InsertLeave
let g:OmniSharp_highlight_types = 2

augroup omnisharp_commands
    autocmd!

    " Show type information automatically when the cursor stops moving
    autocmd CursorHold *.cs call OmniSharp#TypeLookupWithoutDocumentation()

    " The following commands are contextual, based on the cursor position.
    autocmd FileType cs nnoremap <buffer> gd :OmniSharpGotoDefinition<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>fi :OmniSharpFindImplementations<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>fs :OmniSharpFindSymbol<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>fu :OmniSharpFindUsages<CR>

    " Finds members in the current buffer
    autocmd FileType cs nnoremap <buffer> <Leader>fm :OmniSharpFindMembers<CR>

    autocmd FileType cs nnoremap <buffer> <Leader>fx :OmniSharpFixUsings<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>tt :OmniSharpTypeLookup<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>dc :OmniSharpDocumentation<CR>
    autocmd FileType cs nnoremap <buffer> <C-\> :OmniSharpSignatureHelp<CR>
    autocmd FileType cs inoremap <buffer> <C-\> <C-o>:OmniSharpSignatureHelp<CR>

    " Navigate up and down by method/property/field
    autocmd FileType cs nnoremap <buffer> <C-k> :OmniSharpNavigateUp<CR>
    autocmd FileType cs nnoremap <buffer> <C-j> :OmniSharpNavigateDown<CR>

    " Find all code errors/warnings for the current solution and populate the quickfix window
    autocmd FileType cs nnoremap <buffer> <Leader>cc :OmniSharpGlobalCodeCheck<CR>
augroup END

" Contextual code actions (uses fzf, CtrlP or unite.vim when available)
nnoremap <Leader><Space> :OmniSharpGetCodeActions<CR>
" Run code actions with text selected in visual mode to extract method
xnoremap <Leader><Space> :call OmniSharp#GetCodeActions('visual')<CR>

" Rename with dialog
nnoremap <Leader>nm :OmniSharpRename<CR>
nnoremap <F2> :OmniSharpRename<CR>
" Rename without dialog - with cursor on the symbol to rename: `:Rename newname`
command! -nargs=1 Rename :call OmniSharp#RenameTo("<args>")

nnoremap <Leader>cf :OmniSharpCodeFormat<CR>

" Start the omnisharp server for the current solution
"nnoremap <Leader>ss :OmniSharpStartServer<CR>
"nnoremap <Leader>sp :OmniSharpStopServer<CR>

" Enable snippet completion
let g:OmniSharp_want_snippet=1

let g:vimspector_enable_mappings = 'HUMAN'

" Auto close brackets
inoremap " ""<left>
inoremap ' ''<left>
inoremap ( ()<left>
inoremap < <><left>
inoremap [ []<left>
inoremap { {}<left>
inoremap {<CR> {<CR>}<ESC>O
inoremap {;<CR> {<CR>};<ESC>O

Craige · 2020-02-19T02:17:33Z

I this problem appears to be exacerbated by quickload. Disabling quickload dropped my memory usage to ~800-1000MB and CPU usage isn't quite as high either.

Both are still higher than VS Code even with quickload disabled.

nickspoons · 2020-02-19T03:06:10Z

Are you comparing memory of the actual OmniSharp.exe process? In my experience the process started by Vim generally idles at a significantly lower memory usage than once started by VScode.

You're using pathogen so I can't easily tell - do you have many other plugins? You're not using YouCompleteMe or coc.nvim by any chance?

Craige · 2020-02-19T03:33:11Z

Yes, I'm comparing the usage of the mono process hosting OmniSharp.exe in both cases.

Several other plugins are enabled:

➜  14SixtyEightWeb git:(f/steppingforward) ✗ cd ~/.vim/bundle
➜  bundle ls -lah
total 24
drwxr-xr-x  24 craige  staff   768B Feb 15 18:39 .
drwxr-xr-x  10 craige  staff   320B Feb 18 20:26 ..
-rw-r--r--@  1 craige  staff   8.0K Nov 24  2018 .DS_Store
drwxr-xr-x  23 craige  staff   736B Dec 30 16:51 ale
drwxr-xr-x   6 craige  staff   192B Feb 13 17:33 asyncomplete-ultisnips.vim
drwxr-xr-x  11 craige  staff   352B Feb 13 16:57 asyncomplete.vim
drwxr-xr-x   8 craige  staff   256B Aug 30  2017 asyncrun.vim
drwxr-xr-x  28 craige  staff   896B Mar  6  2019 command-t
drwxr-xr-x   9 craige  staff   288B Aug 31  2017 dash.vim
drwxr-xr-x  15 craige  staff   480B Mar  7  2019 nerdtree
drwxr-xr-x  22 craige  staff   704B Dec 16 18:04 omnisharp-vim
drwxr-xr-x  13 craige  staff   416B Oct 12  2017 tcomment_vim
drwxr-xr-x  17 craige  staff   544B Aug 29  2017 tlib_vim
drwxr-xr-x  30 craige  staff   960B Feb 13 17:27 ultisnips
drwxr-xr-x   7 craige  staff   224B Aug 29  2017 vim-addon-mw-utils
drwxr-xr-x  16 craige  staff   512B Mar  7  2019 vim-airline
drwxr-xr-x   9 craige  staff   288B Mar  7  2019 vim-airline-themes
drwxr-xr-x  17 craige  staff   544B Dec 30 16:47 vim-csharp
drwxr-xr-x   5 craige  staff   160B Sep  3  2017 vim-fubitive
drwxr-xr-x   8 craige  staff   256B Sep  3  2017 vim-fugitive
drwxr-xr-x   7 craige  staff   224B Aug 29  2017 vim-php-namespace
drwxr-xr-x   9 craige  staff   288B Feb 15 18:39 vim-sharpenup
drwxr-xr-x  15 craige  staff   480B Dec 24 20:29 vim-snippets
drwxr-xr-x  30 craige  staff   960B Feb 15 17:23 vimspector

Not using YouCompleteMe, but I am using Asyncomplete.

Here's a couple of screenshots

Since turning off quickload, I think things have improved, but they are still not right. The memory usage in those two screen shots actually are closer, but what is far off is the speed at which VSCode completes it's project parsing. It completes in a moment (settling memory/cpu usage being my factors for determining "done", as I don't have an objective signal to read in both cases beings OmniSharp runs in the background), while OmniSharp.Vim takes several to complete and settle down. The OmniSharp.vim spooled process also reaches 2GB of memory while starting up before dropping back down. The VSCode spooled process barely tops 1GB, if it even reaches that.

Of final note, I'm having trouble with OmniSharp.vim declaring the symbols (class, method, properties) of the first file I open as duplicates. It doesn't matter which file I open, but it always appears to only affect the first file.

nickspoons · 2020-02-19T03:56:50Z

It actually just sounds like your server isn't starting properly in Vim. There are some issues that I'm trying to get resolved regarding when to consider OmniSharp-roslyn to be "ready", see OmniSharp/omnisharp-roslyn#1521. It definitely sounds like g:OmniSharp_server_stdio_quickload is hurting here, and letting Vim send requests to OmniSharp-roslyn too early.

What message is echoed when the server is "ready"? "Loaded server for ....sln"? Or "Server load notification for ... not received after 20 seconds"?

Could you try, for the sake of experiment, nudging your g:OmniSharp_server_loading_timeout up to 60 and see what happens? I'm hoping you don't get duplicates after those 60 seconds, and the memory usage goes down.

If not, please post the output of :OmniSharpOpenLog (clear it and restart Vim, then post the output of a clean session).

Craige · 2020-02-19T06:20:20Z

I believe the diagnostic issue is similar, but it doesn't return an error. Instead, diagnostics are returned indicating that all classes/methods are duplicates: The namespace '...' already contains a definition for '...'.

That's exactly what I'm seeing when I mentioned the duplicate symbols. So it seems at least that part is related to that ticket.

Whether that is related to the memory usage/startup cpu usage might remain to be seen. I'll try the loading_timeout tomorrow and see what happens, and will get some logs for you as well.

nickspoons · 2020-02-19T10:22:52Z

OK I've done a bit of testing - that OrchardCore solution is huge - 172 projects. At first I thought I was seeing erroneous behaviour too, but actually it just takes a damn long time for OmniSharp-roslyn to load the solution. I ended up setting g:OmniSharp_server_loading_timeout = 600 (10 minutes). Once it finally loaded, it all worked perfectly.

Running Vim and VSCode side-by-side in Windows, The OmniSharp.exe process started by OmniSharp-vim settled at 694MB memory and 0% CPU after 6-7 minutes. The OmniSharp.exe process didn't really settle for much longer - once it was finished loading, it started "Analyzing" projects one by one. I don't know what this entails but the process stayed around 3GB memory and 25-30% CPU the entire time. It finally stopped analyzing after much longer, 20 minutes or so, with a final memory footprint of 2,962MB.

nickspoons · 2020-02-19T10:24:30Z

Ohhhh. I've just looked more closely at your screenshots and I see what's happening. VSCode is only loading the single project - not the entire solution. Whereas OmniSharp-vim always looks for a .sln first and in this case it finds it ... so it loads everything.

nickspoons · 2020-02-19T10:53:12Z

So there are a couple of ways you can tell OmniSharp-vim to just start OmniSharp-roslyn with just the current project.

let g:OmniSharp_start_server = 0, then start the server manually with :OmniSharpStartServer /path/to/project/dir, or just :OmniSharpStartServer . when the Vim cwd is the project dir.

Create a temporary .sln for working with this project:

cd src/OrchardCore.Modules/OrchardCore.ContentFields
dotnet new sln
dotnet sln OrchardCore.ContentFields.sln add OrchardCore.ContentFields.csproj

Personally I prefer the 2nd option. Either way OmniSharp-vim starts up within a few seconds.

Craige · 2020-02-24T23:15:29Z

Will circle back around to this this week. Sorry for the delay.

nickspoons · 2020-03-23T22:08:25Z

Are you happy for me to close this issue, @Craige? The workarounds I described should solve the issue?

The alternative I suppose is to add an option for OmniSharp-vim to search for .csproj files instead of / as well as .sln files, and start the server when it hits a .csproj. In this situation that would make O#vim work like VSCode.

tschin-futschi · 2023-07-02T17:28:05Z

Found the same problem. using VIM+omnisharp-vimce, once operating on large .cs file, i can feel that vim will be waiting for the response of the server. For example when I editting a file with more than 10000 lines, hitting h,j,k,l, vim stuck there for 2-3 seconds, by the same time CPU usage is around 10% for omnisharp.exe, ~600 MB RAM. However if the current .cs file is not large (< 1000 lines), then everything is perfect.

tschin-futschi · 2023-07-02T17:30:38Z

Anything I can do to improve the performance of omnisharp-vim editting large .cs file?

nickspoons · 2023-07-02T22:25:48Z

Try turning off syntax highlighting.

10,000 lines in a single file of code? Really?

Craige · 2023-07-02T23:24:38Z

Anything I can do to improve the performance of omnisharp-vim editting large .cs file?

Sounds like you need to refactor.

At they very least, splitting your class into partial classes may help. More realistically, you need a larger refactoring to separate concerns.

Your class is doing too much.

tschin-futschi · 2023-07-03T04:37:36Z

Thanks guys!

The project is legacy, pile of shit, have to work on that.
checked with "syntax off" option, no improvement at all.

The symptons of the issues is like.: After opened a >10000 lines .cs file, vim takes ~10 seconds to get everything loaded.

Once I changed the .cs file a little bit, then saved the file. After 4-5 seconds, vim will stuck for around 3-4 seconds. That is very annoying.

So I wanna be sure if this is the limmit of VIM + Omnisharp-vim solution, or I have to switch to VS (which i am realy not a fan of)

nickspoons · 2023-07-03T06:53:28Z

I've never opened a file that big in omnisharp-vim. I'll be very curious to hear how it runs in vscode, for comparison

tschin-futschi · 2023-07-03T08:28:28Z

The other guy here is editting his .cs file with more than 30000 lines, he says pretty OK, no stuck behavior as vim did.
Only one concern, high CPU consumption.
Simple question, what is the "proper" line count for a well developed C# code?
We are here making a uppper computer Application for embedded system. The UI designer is always large.

nickspoons · 2023-07-03T10:27:15Z

Well there's no concrete answer. Ideally it's nice to keep a code file to a size that can be viewed on a screen, but realistically C# has a fair bit of boilerplate so 500-1000 isn't unusual but it's not nice to work with.

The other guy here is editting his .cs file with more than 30000 lines, he says pretty OK, no stuck behavior as vim did.

This is too vague to be useful. The same computer running the same project would be a useful comparison.

tschin-futschi · 2023-07-05T11:26:15Z

Tried out on my computer, same code. There is no noticable delay using Visual Studio.
All functions,: Goto definition, references, peeking code in a beneath windows work smoothly.

Everything is nearly perfect, when dealing with large .cs file using Visual studio.

Tried on neovim-qt as well, same problem as the original vim.

The drawback makes vim almost no competitive edge versus visual studio.

nickspoons · 2023-07-05T11:34:49Z

Are you talking about Visual Studio or Visual Studio Code? Please try with Visual Studio Code, and ideally compare the logs.

tschin-futschi · 2023-07-05T11:44:03Z

I am using Visual Studio, not Visual Studio Code.

Sorry no visual studo code installed on my computer.

nickspoons · 2023-07-05T11:52:50Z

Ok. VS has a totally different engine.

Turning off syntax highlighting will make omnisharp-vim work faster on your huge file. Beyond that, you're teaching limitations of omnisharp.

tschin-futschi · 2023-07-05T12:02:27Z

Thanks you guy. Maybe good time for me to learn Visual studio for all the .cs stuff.

nickspoons closed this as completed Apr 13, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Omnisharp takes excessive time and memory usage when fired from Omnisharp-vim #558

Omnisharp takes excessive time and memory usage when fired from Omnisharp-vim #558

Craige commented Feb 19, 2020 •

edited

Loading

nickspoons commented Feb 19, 2020

Craige commented Feb 19, 2020

Craige commented Feb 19, 2020 •

edited

Loading

nickspoons commented Feb 19, 2020

Craige commented Feb 19, 2020 •

edited

Loading

nickspoons commented Feb 19, 2020

Craige commented Feb 19, 2020

nickspoons commented Feb 19, 2020

nickspoons commented Feb 19, 2020

nickspoons commented Feb 19, 2020 •

edited

Loading

Craige commented Feb 24, 2020

nickspoons commented Mar 23, 2020

tschin-futschi commented Jul 2, 2023

tschin-futschi commented Jul 2, 2023

nickspoons commented Jul 2, 2023

Craige commented Jul 2, 2023

tschin-futschi commented Jul 3, 2023

nickspoons commented Jul 3, 2023

tschin-futschi commented Jul 3, 2023

nickspoons commented Jul 3, 2023

tschin-futschi commented Jul 5, 2023

nickspoons commented Jul 5, 2023

tschin-futschi commented Jul 5, 2023

nickspoons commented Jul 5, 2023

tschin-futschi commented Jul 5, 2023

Omnisharp takes excessive time and memory usage when fired from Omnisharp-vim #558

Omnisharp takes excessive time and memory usage when fired from Omnisharp-vim #558

Comments

Craige commented Feb 19, 2020 • edited Loading

nickspoons commented Feb 19, 2020

Craige commented Feb 19, 2020

Craige commented Feb 19, 2020 • edited Loading

nickspoons commented Feb 19, 2020

Craige commented Feb 19, 2020 • edited Loading

nickspoons commented Feb 19, 2020

Craige commented Feb 19, 2020

nickspoons commented Feb 19, 2020

nickspoons commented Feb 19, 2020

nickspoons commented Feb 19, 2020 • edited Loading

Craige commented Feb 24, 2020

nickspoons commented Mar 23, 2020

tschin-futschi commented Jul 2, 2023

tschin-futschi commented Jul 2, 2023

nickspoons commented Jul 2, 2023

Craige commented Jul 2, 2023

tschin-futschi commented Jul 3, 2023

nickspoons commented Jul 3, 2023

tschin-futschi commented Jul 3, 2023

nickspoons commented Jul 3, 2023

tschin-futschi commented Jul 5, 2023

nickspoons commented Jul 5, 2023

tschin-futschi commented Jul 5, 2023

nickspoons commented Jul 5, 2023

tschin-futschi commented Jul 5, 2023

Craige commented Feb 19, 2020 •

edited

Loading

Craige commented Feb 19, 2020 •

edited

Loading

Craige commented Feb 19, 2020 •

edited

Loading

nickspoons commented Feb 19, 2020 •

edited

Loading