When is the best time to use CGO?

<hr/>**评论：**<br/><br/>Manbeardo: <pre><p>In my experience, I&#39;ve found it best to avoid using cgo when possible. The reasons I might want to use cgo are:</p> <ul> <li>The functionality you want doesn&#39;t exist as a go library and implementing it yourself would be too costly.</li> <li>Your algorithm needs to run faster and you&#39;re pushing the go runtime to it&#39;s limit.</li> </ul> <p>The reasons I don&#39;t typically want to use cgo are:</p> <ul> <li>Calling into cgo comes at a very real cost. Cleaning up the stack going into and out of C isn&#39;t cheap.</li> <li>cgo builds are slower.</li> <li>cgo builds are harder to set up. You introduce components that aren&#39;t <code>go get</code>-able and you often don&#39;t want to build from source.</li> <li>cgo and concurrency are not friends. Concurrency isn&#39;t on by default in C, so you&#39;re going to need to think about thread safety and consider that your go functions may jump between threads mid-execution if you don&#39;t lock them down.</li> <li>cgo deployments are harder. You now have to include dynamic libraries. This means you need a real deployment tool and you have to be much more careful in development. It&#39;s really easy to use the wrong version of a library on your dev machine.</li> </ul> <p>In light of that, I avoid using cgo unless it is <em>absolutely necessary</em>.</p></pre>jimuazu: <pre><p>Let&#39;s say I need to talk to a C-based rendering library and pass a relatively limited amount of data to it. I wonder, would it be faster to do CGO calls directly to the rendering library, or else start another POSIX thread or external process to run the C code in and use IPC or socketpair() or FIFO or similar to transfer my updates to it?</p> <p>In other words I could keep the Go world and the C world completely separate to avoid the locking overhead in Go when it needs to switch between C and Go, and instead pay for some locking on a communication channel. (Also, using a communication channel and a simple update protocol makes it easier to batch up updates into a single &#39;flush&#39; now and then, reducing locking even further.)</p> <p>It is said that Google Chrome uses socketpair() to communicate even framebuffer data between processes on Linux and OSX, so it can&#39;t be all that slow, although it needs trying to be sure.</p></pre>barsonme: <pre><p>IIRC rsc said calling C from Go is roughly equipment to 9 function calls.</p> <p>I&#39;ll dig up the gonuts thread in a bit. M</p></pre>gohacker: <pre><p>When you don&#39;t feel like porting ffmpeg to Go.</p></pre>tkreadit: <pre><p>What if you have to interact with some hardware (on Linux) via a C API/library that exists in user space and talks to a kernel driver? Would you use cgo against the library or instead look at making syscall/ioctl calls from Go?</p></pre>moosingin3space: <pre><p>If the C library were open-source, I&#39;d look at its source and make syscalls from Go. </p></pre>tkreadit: <pre><p>It is, well not really, it&#39;s written in-house so I do have access to the source, with the advantage that I can ask the author. Trouble is that it&#39;s still being actively developed so I&#39;d have to keep up with the changes. Same problem with using the C API though. I was toying with the idea of asking the developer to provide some sort of RPC or IPC instead that he could maintain instead, it would make it easier to call from Go (performance is not critical in this case).</p></pre>i_regret_most_of_it: <pre><p>A common one might be if you need to use sqlite</p></pre>