ycm-core / YouCompleteMe

A code-completion engine for Vim
http://ycm-core.github.io/YouCompleteMe/
GNU General Public License v3.0
25.44k stars 2.81k forks source link

YCM killing my vim with GoLang #1461

Closed cfsalguero closed 9 years ago

cfsalguero commented 9 years ago

Since a couple of days, YCM started to use 99% CPU when using it with Go. I've disabled Syntastic but there is no change. There is any way to make it compile only when saving?

vheon commented 9 years ago

The go completer was merged 18 hours ago, so If you're saying that you have been experience these CPU overuse since a couple of days might not be YCM related. Are you working with large file by any chance?

cfsalguero commented 9 years ago

Yes, I'm working with a really big project but, I ran PlauginInstall to update all plugins and everything seems to be working fine again. Thank you so much. You made my day better.

vheon commented 9 years ago

@cfsalguero I was worried that you were experiencing CPU burst from this function. So if you still get those let us know.

cfsalguero commented 9 years ago

It seems to be working much better but I'm still having issues when writing strings (even having let g:ycm_complete_in_strings = 0) or when the list of candidates is too long. I'm going to investigate more before reopening the issue.

cfsalguero commented 9 years ago

How can I debug it?

That is a very good question but I don't have a good answer.

vheon commented 9 years ago

Try to use YCM as always and if you experience the same behaviour then we could think to add some logging to that function to see if that is the real cause.

cfsalguero commented 9 years ago

Hi again,

Probably I would need to change the title and remove the word "killing', but it is working super slow. Mainly on file having 200+ lines. Please let me know if I can send you a log or something.

Thanks.

Valloric commented 9 years ago

@ekfriis You might have some ideas.

ekfriis commented 9 years ago

Two ideas off the top of my head to narrow things down:

Is it the ycmd process or the gocode process that is saturating the CPU?

Are you completing things that have a lot of stuff that are possible completions? Example: a package with 10k costs defined in it.

ekfriis commented 9 years ago

s/costs/consts/

@Valloric that would violate causality

Valloric commented 9 years ago

@ekfriis You can edit your comments on github. :) There's a little pencil icon in the top-right corner of a comment.

cfsalguero commented 9 years ago

Don't know how to tell. I only see vi using 100% CPU. I'm online most part of the day. If you wish, I can help you using G+

Valloric commented 9 years ago

If vim is using 100% CPU, this is unlikely to be caused by YCM; most YCM logic happens in ycmd, which is a separate process.

Do you perhaps have other vim plugins installed that might be interacting badly with YCM here? Try to reproduce the problem with only YCM loaded in your vimrc.

cfsalguero commented 9 years ago

One more thing. In Go you can have multiple files for the same package. Another file, not the one I was editing, had an error, and an error in the imports, so the errors list was almost empty because Go was only saying:

$ go build
can't load package: import cycle not allowed
package github.com/XXXXXXX/db/mysql
        imports github.com/XXXXXXX/db/mysql
import cycle not allowed

After fixing that, it started to work much better. BTW, I've already tried only having YCM running and it was the same.

ekfriis commented 9 years ago

One idea: run in terminal

gocode -in=yourfile.go autocomplete yourfile.go 200 (or some other number, this is the byte offset in the file to find completions for)

If this bless up the CPU, it is gocodes fault.

On Thu, Apr 16, 2015, 14:18 Carlos Salguero notifications@github.com wrote:

One more thing. In Go you can have multiple files for the same package. Another file, not the one I was editing, had an error, and an error in the imports, so the errors list was almost empty because Go was only saying:

$ go build can't load package: import cycle not allowed package github.com/XXXXXXX/db/mysql imports github.com/XXXXXXX/db/mysql import cycle not allowed

After fixing that, it started to work much better. BTW, I've already tried only having YCM running and it was the same.

— Reply to this email directly or view it on GitHub https://github.com/Valloric/YouCompleteMe/issues/1461#issuecomment-93841729 .

cfsalguero commented 9 years ago

I dind't found a super slow line yet, but I was able to see (trying several times) a message that says: RuntimeError: Gocode returned empty json response When that happens, the editor becomes slow.

ekfriis commented 9 years ago

@Valloric will YCM behave nicely if I throw exceptions in the case I don't understand the output from gocode? That is what I do now, for cases like @cfsalguero's above but I could just as easily return an empty set of completions instead of throwing.

vheon commented 9 years ago

@ekfriis will gocode tell us something if there are some error in the file? or it would just return an empty json?

ekfriis commented 9 years ago

Trying to do some completions on a garbage file, AFAICT it just returns an empty json. Is YCM expected to report compile errors? IMO I should change that RuntimeException to just return an empty set of completions.

vheon commented 9 years ago

@ekfriis I'm not sure that return an empty set will be an optimal choice, I mean: I write some_var. and expect the possible candidates and no error are shown nor the completion.

YCM report compile errors if the completion engine is able to provide some. If you write C/C++ you get compiler errors, if you write python then you don't get those, since jedi don't generate errors, @Valloric can correct me if I'm wrong.

Valloric commented 9 years ago

@ekfriis If we know that we're not producing completions because of an error in the semantic engine, then we should report an error (by throwing an exception). See how the clang_completer handles it. YCM will then show that exception message in the Vim status area.

On the other hand, if we know that there really are no completions to be offered, no error should be shown. The clang_completer currently errs on the side of always showing the error message if it never gets completions but that's because it's extremely rare to encounter a situation where libclang truly doesn't have anything to show.

cfsalguero commented 9 years ago

Hi, Just wanted to say that this is hard to debug and I don't want to make you lose time with theory. For example, after the last update (just now) I've noticed completion is slow displaying/choosing the list of options. I was writing Go code and upon writing http.Status, since that list is quite long, then it became slow. Sorry for not being able to give you more accurate information. For me, it is Ok if you close the thread. I need syntastic more than the auto-completion so it is Ok. Thank you anyways.

oblitum commented 9 years ago

@cfsalguero have you checked vim-go? I use it with syntastic and YCM daily and it has more mileage. I'm not sure what's gonna happen when I update YCM, I guess just not building it with go-completer enabled will do the trick to keep my current setup.

oblitum commented 9 years ago

@cfsalguero In truth, I've specifically disabled active syntastic for Go since it did more harm than good for me:

oblitum commented 9 years ago

At the time I've concluded syntastic default setup wasn't good enough or taken with care. There's a long discussion related with those one mentioned previously:

Hence, I've preferred to have more specific plugins than have active syntastic enabled.

ekfriis commented 9 years ago

Hi @oblitum,

For better or worse, if the gocode binary is on your path YCM will start using it to do Golang completion (and override the omnifunc which vim-go defines). @Valloric, do you think we should provide an override option? If we use the YCM blacklist option, will that kill the YCM omnifunc completion?

In principle the new YCM implementation should be categorically better in terms of latency. It would be great if you could give it a try and let me know if you find otherwise!

cfsalguero commented 9 years ago

Even with syntastic disabled, YCM is imposible to use for me. As I've mentioned, autocompetion on http.Status take ages to move the cursor just 1 line down.

oblitum commented 9 years ago

In principle the new YCM implementation should be categorically better in terms of latency. It would be great if you could give it a try and let me know if you find otherwise!

@ekfriis Will do when I get some free-time. One thing is that I'm quite content with vim-go already, simply I have no latency, it was never a problem regardless of the packages I use, and my job machine is a very modest linux laptop.

cfsalguero commented 9 years ago

Seems like it is trying to update the list every time I press the down arrow to move to the next option. Can it be disabled while choosing from the list of alternatives? Probably it is a stupid idea, but I think not adding the "proposed" text in the code until you press enter on the suggestion you want, should fix the issue.

ekfriis commented 9 years ago

@cfsalguero If you run, in a terminal:

/path/to/ycmd/third_party/gocode/gocode close /path/to/ycmd/third_party/gocode/gocode -s -debug

it will run the gocode server process in your shell, and you can see each time gocode is being called. it should only be called once after you type the "." after "http", can you verify this is the case?

cfsalguero commented 9 years ago

Go code is being called at start of typing the S after the dot. I'm writing http. then the S for status, go code is being called, a pop up is being open having the list in it, and I start pressing the down arrow to move to the next option, at that moment it becomes ultra slow, gocode is not being called again and in the status I see: -- User defined completion (^U^N^P) match 20 of 123

ekfriis commented 9 years ago

Do you have vim-go enabled? if so, can you try doing it with it disabled?

cfsalguero commented 9 years ago

It is a little bit faster without vim-go, but I think it is just because it found less matching words. Now it says: -- User defined completion (^U^N^P) match 3 of 42

If I use auto-completion on things like revel_controller.R to get a list like Result, Render, Request, etc, it finds only 19 matching words and the speed is not fast but acceptable. -- User defined completion (^U^N^P) match 11 of 19

vheon commented 9 years ago

I'm not sure what's gonna happen when I update YCM, I guess just not building it with go-completer enabled will do the trick to keep my current setup.

@oblitum that won't be enough. YCM will check if a Native completer exists for the go filetype by looking if the file ycmd/completers/<filetype>/hook.py exists, and evey if you install YCM without the --gocode-completer YCM will think that it has a Native completer for go and ignores the omnifunc.

oblitum commented 9 years ago

@vheon Yeah, thanks. I've got double confirmation of that, so it seems I should be afraid of =[ ]

vheon commented 9 years ago

@Valloric could we do something like it is with clang completer? So checking if the user have set the appropriate flag in the build process?

ekfriis commented 9 years ago

@cfsalguero is it possible for you to share the code you are working on (or a minimal test case)?

cfsalguero commented 9 years ago

I'll try to do it with an open source project I'm currently working on.

Valloric commented 9 years ago

@vheon We could do it that way, sure.

ekfriis commented 9 years ago

Hi @cfsalguero,

Another thought - can you check what gocode binary you are using? If you look at the stderr file reported by :YcmDebugInfo at the top you should see a line like "Enabling go completion using [path to binary"

cfsalguero commented 9 years ago

What I've found is that disabling vim-go t works a lot better. Another thing I've found is that when vim-go is enabled, it becomes super slow just after opening a parenthesis I'm using the gocode in my gopath. Which gocode returns /home/karl/golang/bin//gocode

cfsalguero commented 9 years ago

Remember, I'm online with my email. Feel free to contact me on G+

ekfriis commented 9 years ago

Hi @cfsalguero, I tried to recreate the slowness w/ vim-go with this minimal vimrc (following the install instructions at gmarik/Vundle.vim, Valloric/YouCompleteMe, and fatih/vim-go, respectively) and doing completions in the nsf/gocode package, but it seems okay to me:

set nocompatible              " be iMproved, required
filetype off                  " required

" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()

" let Vundle manage Vundle, required
Plugin 'gmarik/Vundle.vim'
Plugin 'Valloric/YouCompleteMe'
Plugin 'fatih/vim-go'

call vundle#end()            " required
filetype plugin indent on    " required
syntax on

Can you try with this setup and/or post your vimrc?

cfsalguero commented 9 years ago

This is the link to my vimrc https://github.com/cfsalguero/vim_config

cfsalguero commented 9 years ago

There is any irc channel to talk? For example, I've updated my plugins today and now I have omni completion instead of gocode. It is really frustrating not knowing if it is a configuration issue, if it is related to the plugins I have or what is happening

ekfriis commented 9 years ago

Hi @cfsalguero it is hard for me to communicate synchronously on IRC or equivalent - can you try the minimal vimrc above and see if you still have problems?

cfsalguero commented 9 years ago

with the minimal version it works Ok

ekfriis commented 9 years ago

When I have a problem with my vimrc, I usually find the best way to debug is to binary search - comment out half the vimrc, see if problem is still there, recurse into that half, etc.

On Fri, Apr 24, 2015 at 9:50 AM Carlos Salguero notifications@github.com wrote:

with the minimal version it works Ok

— Reply to this email directly or view it on GitHub https://github.com/Valloric/YouCompleteMe/issues/1461#issuecomment-95990171 .

cfsalguero commented 9 years ago

I did what you said, comment out most of my .vimrc and started over. It works know and I disabled syntastic. The only thing I miss is having the lines with errors marked in red in the gutter column. There is any way of having that with YCM? Other than that, I'm closing this issue Thanks

ekfriis commented 9 years ago

Hi @cfsalguero, so what exactly were the lines that were bad in the end? If possible I would like it to work nicely with syntastic