nsf / gocode

An autocompletion daemon for the Go programming language
MIT License
5.01k stars 659 forks source link

Completion results are sometimes slow #345

Open r4nt opened 8 years ago

r4nt commented 8 years ago

When completing large modules (fmt.) completion time is sometimes > 0.5 seconds, which leads to problems trying to use gocode with YCM [1].

[1] https://github.com/Valloric/YouCompleteMe/issues/742 @Valloric

nsf commented 8 years ago

I need reproducable test case for this. Typical gocode autocompletion time on fmt. is around 0.03s (30ms). Half a second is a very long time. Perhaps it's due to autobuild feature?

chenyuewu commented 8 years ago

@nsf You can try this python script to reproduce import numpy as np a = np.zeros((3,3)) At most time it takes more than 0.5s for my computer to respond to a = np..

nsf commented 8 years ago

Lol, what python has to do with gocode?

chenyuewu commented 8 years ago

My bad, I thought it was in youcompleteme. lol

cpuguy83 commented 8 years ago

For me, completion is pretty much always slow on complex objects (github.com/docker/docker/daemon.Daemon, for example). Not surprisingly there is tons of time spent in GC.

Attached is a flame graph as well as pprof output for alloc space. This is from attempting completion on the above type several times as well as github.com/docker/docker/container.Container... all 2 minutes worth of capture. gocode-profile.zip

oblitum commented 7 years ago

Reproducible in C and C++ too as explained in https://github.com/Valloric/YouCompleteMe/issues/777#issuecomment-236626561. YCM is unable to cope with a large number of keys for presenting a popup menu in timely manner, where the presented menu content itself is just a small part of all the results obtained. It makes YCM slow in most slightly large codebases. The issue is very relevant in C codebases or when using C APIs where forced semantic completion of symbols in global namespace is the main usecase for semantic completion, but since the global namespace is full of symbols, YCM doesn't handle it well and responds slowly or just timeout.

It's possible that the complete_add API (or the newer async features) may help in a solution that makes partial results available for display while not all the results have been processed yet. complete_add can do it in synchronous fashion:

oblitum commented 7 years ago

ops, my bad, I also thought this issue was in youcomplete lol... I think it's due to youcompleme to fix this in a general way. Regarding gocode, given what I've described above, if YCM could make results available partially as eager as possible, then the issue would be due to gocode alone only if it was slow to give any results at all, since YCM could do nothing to make the results come faster in any sense (except of course, when there's caching solution involved).

So, if gocode is just not giving the results in timely manner, YCM can't do nothing about it, gocode must fix it. But still, there's also the issue where there are results in a fast manner from gocode, but YCM may not handle it fast when there's too much data, which is the issue I comment above and happens with C too.