nsf
commented
6 years ago It's a wrong assumption on your side. There is this thing called file cache. Most operating systems do have one. OS caches recently read files in-memory in case if you have free RAM for it. Usually these days people have quite a lot of RAM. Assumption that binary is always re-read from HDD is wrong. I can guarantee that this does not happen on linux. Most likely same behaviour is true for other modern OSes as well.
Now as for what visual studio code plugin does - I don't know. With the right setup gocode can return autocompletion response in less than ~100ms for most cases. However "gocode set" command drops gocode cache and gocode ends up re-reading the whole set of libraries your currently edited project uses. Blame vscode plugin authors for that if that's true. If you want an advice from me: gocode set should never be used by any of the editor plugins. And even more: most gocode users should not use lib-path config option. It was added as hack to handle weird setups such as google's appengine Go integration in the early days. I'm not sure if it's relevant anymore.
I will not add RESTful API to gocode. Hopefully sooner or later gocode will be replaced by a better language server protocol based service if somebody writes it.
I am using visual studio code + go extension, when request autocomplete ,first send 'gocode set' to get config,then send custom config like gocode set lib-path '/', after that send gocode autocomplete.. command to get autocomplete list. It will call gocode program(about 10M) three times, I'm not using ssd,so it const about 1.2 seconds to show the autocomplete list. Simply, I modified the gocode client code, add http service(37374) for commands, and write results to http response, then modified the vsc-go plugin ,using http method instead of calling gocode . After that, it's very very fast. So, I think gocode server can provide a restful api .