Closed cfsalguero closed 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?
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.
@cfsalguero I was worried that you were experiencing CPU burst from this function. So if you still get those let us know.
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.
How can I debug it?
That is a very good question but I don't have a good answer.
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.
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.
@ekfriis You might have some ideas.
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.
s/costs/consts/
@Valloric that would violate causality
@ekfriis You can edit your comments on github. :) There's a little pencil icon in the top-right corner of a comment.
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+
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.
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.
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 .
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.
@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.
@ekfriis will gocode
tell us something if there are some error in the file? or it would just return an empty json?
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.
@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.
@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.
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.
@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.
@cfsalguero In truth, I've specifically disabled active syntastic for Go since it did more harm than good for me:
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.
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!
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.
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.
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.
@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?
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
Do you have vim-go enabled? if so, can you try doing it with it disabled?
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
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
.
@vheon Yeah, thanks. I've got double confirmation of that, so it seems I should be afraid of =[ ]
@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?
@cfsalguero is it possible for you to share the code you are working on (or a minimal test case)?
I'll try to do it with an open source project I'm currently working on.
@vheon We could do it that way, sure.
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"
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
Remember, I'm online with my email. Feel free to contact me on G+
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?
This is the link to my vimrc https://github.com/cfsalguero/vim_config
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
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?
with the minimal version it works Ok
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 .
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
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
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?