"go tool" server - is there any use for it?

<p>One obsessive idea drives me crazy. Currently all lightweight code editors I know (Sublime, VS Code, Atom) use go tools: <code>go fmt</code>, <code>golint</code>, <code>gocode</code>, etc. But each time an action is executed, the go tool is actually invoked with shell command, like <code>sh: go fmt .</code>. I&#39;m just thinking: what if there is a server continiousely running that keeps all the go tools in memory? In such a case an editor doesn&#39;t need to invoke a command with shell but rather communicate to a server (using some binary messaging protocol maybe?). Such approach could remove some overhead on loading the tool into memory, parsing arguments and parsing response of the tool.</p> <p>AFAIK there is MarGo (<a href="https://github.com/DisposaBoy/GoSublime/tree/master/src/disposa.blue/margo" rel="nofollow">https://github.com/DisposaBoy/GoSublime/tree/master/src/disposa.blue/margo</a>) which implements something like I described above. Just wondering whether this idea makes any sense to implement. Will it help editors run go tools a little bit faster (thus make whole code writing experience better)?</p> <hr/>**评论：**<br/><br/>dlsniper: <pre><p>The idea won&#39;t help.</p> <p>The problem with the tools is not the invocation from the editor but the fact that they need to parse the source tree again and again (as well as resolve the types, make sure they can apply their logic on them and so on). Those tools will be cached in the memory of your machine as soon as you request them from the disk the first time around. So will the files that they are inspecting. In the off-chance they are removed from the cache, they&#39;ll be added again as soon as they are needed.</p> <p>This is one of the main advantages of IntelliJ and proper IDEs / editors, they don&#39;t need to do this, they already have all the information they need in memory to run the code checks.</p></pre>el_gris: <pre><p>Hm... Ok, and what if we &#34;improve&#34; this kinda useless idea with ability to index and cache source code tree? At the end you&#39;ll get something very similar to what modern IDEs have, but available for lightweight editors as well.</p></pre>dlsniper: <pre><p>To understand a bit of this, have a look at this video: <a href="https://www.youtube.com/watch?v=oWwcdz3WNKQ&amp;index=4" rel="nofollow">https://www.youtube.com/watch?v=oWwcdz3WNKQ&amp;index=4</a></p> <p>As for the &#34;update&#34; you&#39;d basically need to have all the tools changed to benefit from working on the cached version and make sure that on every save you parse the files and so on. Sure, you could do that for all the tools, but that&#39;s quite a bit of work.</p></pre>natefinch: <pre><p>Are the tools slow for you? What problem are you trying to fix?</p> <p>I have a pretty huge gopath, and all the tools run basically instantly for me (less than 250ms), not counting go build/test/etc.</p></pre>FUZxxl: <pre><p>Invoking a command through the shell is very fast. Both the shell and the command is likely already in memory from the last time you invoked a command and shells are very good at parsing commands.</p> <p>It&#39;s fast enough for UNIX, it&#39;s certainly fast enough for you.</p></pre>Matthias247: <pre><p>Very fast is a quite subjective measurement. If you start a subprocess in order to get your work done you have the overhead of starting a process, which is far from low. If you even use the shell to do it then the overhead grows to starting a <code>sh</code> process, which then again starts a process for the desired tool. Having the target process already in memory and communicating with it what you want is certainly a lot faster (again: subjective). That&#39;s also the reason why web servers have gone from the CGI model (spawning a process for each request) to having a set of prespawned processes to handling requests directly in the webserver.</p></pre>FUZxxl: <pre><p>Do you know how long it takes to start a process on a modern UNIX? The latency is pretty much invisible. Even starting a (non interactive) shell and then a Go tool is too fast to see. Web servers stopped using this model because one can indeed get higher performance out of a custom-knit solution, but for something like invoking a compiler, just invoking the binary is both fast enough for all intents and purposes and much more flexible than creating a custom server and protocol.</p> <p>There are of course situations where the shell seriously eats performance, e.g. when executing configure scripts. You can see that by executing them with a shell like <code>ksh93</code> that has special code to avoid forking where possible; runtime drops by as much as 60% on platforms where forking is slow, like Windows. But that is certainly an extreme case.</p></pre>