Completion results are sometimes slow

[r4nt]

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]

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]

@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]

Lol, what python has to do with gocode?

[chenyuewu]

My bad, I thought it was in youcompleteme. lol

[cpuguy83]

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]

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:

• https://github.com/Rip-Rip/clang_complete/pull/187#issuecomment-7965909

[oblitum]

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.