- 原文链接：https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
- 原作者：Tobias Schottdorf
- 原文日期：Dec 9, 2015
- 译：zifeiy
Cgo 是 Go 的一个非常重要的部分：
它是你调用任何任何非Go代码的窗口（或者更确切地说，任何由C语言绑定的东西）。
对于 CockroachDB 来说，
cgo 减轻了我们在处理连接 ROcksDB 的存储层（storage layer）时候的压力，
而 RocksDB 这个存储引擎目前在Go语言生态环境中没有良好的替代品，
至少在我们的任职范围内没有。
经过几次迭代之后，
我们发现处理这些外部库的正确方法——我们有相当多的外部库——是将它们处理后放在Go语言的依赖包（Go wrapper packages）中：
虽然Cgo为我们提供了便利，但是请远没有直接调用那么简单。
经验丰富的Cgo使用者（cgo-er）可能会知道这一点（并且可能更倾向于轻描淡写地在这篇文章的剩余部分上浏览），但是使用Cgo附带一些警告，我们将在下面讨论我们建议的解决方案。
调用的开销（Call Overhead）
调用 Cgo 带来的开销将比在Go语言内部的调用带来的开销大几个数量级。
这听起来很可怕，但实际上在很多应用中都不是问题。
然我们来观察一下这个 cgobench 包：
func BenchmarkCGO(b *testing.B) {
CallCgo(b.N) // call `C.(void f() {})` b.N times
}
// BenchmarkGo must be called with `-gcflags -l` to avoid inlining.
func BenchmarkGo(b *testing.B) {
CallGo(b.N) // call `func() {}` b.N times
}
$ go test -bench . -gcflags '-l' # disable inlining for fairness
BenchmarkCGO-8 10000000 171 ns/op
BenchmarkGo-8 2000000000 1.83 ns/op
换句话说，在这个（公认最小的）例子中，大约有100个因素参与其中。
大家不要因此疯狂。
按照绝对时间，171 ns通常是一个完全可以接受的成本，特别是如果你的C代码做了大量的工作。
然而，在我们的例子中，我们在一些测试中计时了数以万计的Cgo调用，
所以我们把一些代码推到C上以减少迭代次数。
我们的结论是调用开销并不重要，等价的C++和Go的实现在性能上是难以区分的。
然而，由于能够编写更高效的实现，我们仍然将一些操作移到C++上，并进行了fat改进。
手动ISH内存管理（Manual-ish Memory Management）
GO是一门垃圾回收语言，但C不是。
这意味着从C传递数据到Go不应该粗心地进行，并且拷贝常常是不可避免的，反之亦然。
（译者的理解：C语言中的数据不会自动释放，而Go语言中的数据会自动进行垃圾回收，所以在两者之间传输数据的时候可能会碰到数据被提前释放，或者该释放但是没释放的问题）
尤其是（在我们经常）非常频繁地处理字节字符串和接口的时候。
传统的对 C.CString 及 C.GoBytes 的使用会大大增加内存压力，
当然，复制数据也会明显消耗CPU性能。
在一些场景下，我们有办法避免这种类型的拷贝。
举个例子，在便利键的时候，我们使用如下办法：
func (r *rocksDBIterator) Key() []byte {
return C.GoBytes(unsafe.Pointer(r.key), s.len)
}
func (r *rocksDBIterator) Next() {
// The memory referenced by r.key stays valid until the next operation
// on the iterator.
r.key = C.DBNext(r.iter) // cgo call
}
如果我们想要做的是检查一个标准的当前键，我们知道底层内存在我们需要的时候是不会被释放掉的。
因此，这个（编写的）代码似乎是浪费的：
for ; iter.Valid(); iter.Next() {
if bytes.HasPrefix(iter.Key(), someKey) { // copy!
// ...
}
}
为了减轻所有这些拷贝的成本，我们添加（并使用）函数 Key() 的零拷贝（和不安全）版本：
// unsafeKey() returns the current key referenced by the iterator. The memory
// is invalid after the next operation on the iterator.
func (r *rocksDBIterator) unsafeKey() []byte {
// Go limits arrays to a length that will fit in a (signed) 32-bit
// integer. Fall back to copying if our slice is larger.
const maxLen = 0x7fffffff
if s.len > maxLen {
return C.GoBytes(unsafe.Pointer(r.key), s.len)
}
return (*[maxLen]byte)(unsafe.Pointer(s.data))[:s.len:s.len]
}
这看上去是一个更高效和安全的办法，但是在正确使用的时候，它涉及到更多需要考虑的地方。
我们正在创建一个由C分配的内存支持的切片。
我们需要小心，而我们的切片（或任何衍生切片）仍在使用中，而与此同时C内存没有释放。
（译者的理解：C内存没有释放，对切片的改动，不能引起内存的变化，那我们度数据是从内存中读的，
读到的还是原来的数据）
我们可以解决这个问题，因为这个问题出现在我们的底层代码中，但这肯定不是任何类型的面向公众的API的选择；
这将保证一些用户不会遵守对返回的字节切片的微妙契约，并且随机地体验空指针异常。
Cgoroutines != Goroutines
这可能是一个严重的问题，而当你想到它的时候是显而易见的，当你不这样做的时候，它会是一个惊喜。
考虑如下代码：
func main() {
for i := 0; i < 1000; i++ {
go func() {
time.Sleep(time.Second)
}()
}
time.Sleep(2*time.Second)
}
这个无聊的程序不会有多大效果。1000个 gouroutines 几乎免费地来了，分配给它们的“堆栈”只有几千字节。
如果我们把 cgo 带入这个编码游戏呢？
下面的代码是 cgobench 中一个示例的简化版本：
//#include <unistd.h>
import "C"
func main() {
for i := 0; i < 1000; i++ {
go func() {
C.sleep(1 /* seconds */)
}()
}
time.Sleep(2*time.Second)
}
“惊喜”是这段代码的效果（和上面那段）非常不同。
一个阻塞式的 cgo 调用会占用一个系统线程；
Go运行时库 不能像 goroutine 那样调度它们，而堆栈是一个真正的堆栈，其数量是兆字节的！
同样，如果你调用适当的有界并发的 cgo ，那就没什么大不了的。
但是如果你写的话，你可能已经习惯于不太考虑 Goroutines 了。
在关键请求路径中的阻塞cgo调用可能会给你带来成百上千的线程，
这些线程可能会 导致问题。
特别地，ulimit -r 或 debug.SetMaxThreads 可能会导致程序地快速终止。
或者，按照 Dave Cheney 地话来说，
- “过多的 cgo 使用中断 Go 轻量级并发的承诺。”
交叉编译（Cross Out Cross-Compilation）
使用 cgo ，你会丢失（或者更确切地说，你不会很好地体验到）交叉编译在 Go 1.5 或更高把呢不能中工作的易用性。
这并不奇怪（因为交叉编译与C依赖关系必然需要交叉编译C依赖），但是如果您在和Go自己的包或外部库之间进行选择，那么这可能是一个标准。
Dave Cheney在此处发表的一篇文章 通常是关于可用信息的最佳来源。
静态构建（Static Builds）
这种情况和交叉编译的情况类似，不过和交叉编译相比情况较好一点。
使用 cgo 构建静态二进制文件仍然是可能的，但需要进行一些调整。
在Go 1.5之前，最突出的例子是必须使用 netgo 构建标签来避免在 glibc 中链接DNS解析。
这已成为默认的处理方式，
但仍然存在一些微妙之处，
例如必须指定自定义 -installsuffix（以避免使用非静态生成中的缓存生成）、
将正确的标志传递给外部链接器（external linker，在本例中，-extldflags “-static”），
并用 -a 构建以执行一个完全的重建。
不是所有的这些都是必要的，但是你需要明白这一点：
它变得更加手动，并且所有的重建速度都变慢了。
对于所有感兴趣的人来说，
这是我与 cgo 的第一次约会（以及后来的）角斗 和
一个神秘的错误，
我们可以在未来的帖子中再次找到。
调试（Debugging）
调试你的代码会更困难（在使用 cgo 的情况下）。
驻留在C中的部分代码不容易通过Go的工具访问。
PProf、运行时统计（runtime statistics）、行号（line numbers）、
堆栈跟踪（stack traces） —— 当你越过边界时，所有的东西都会减弱。
GoRename 及其朋友可能 偶尔会将源代码中的标识符丢弃 ，
而这些标识符（原本应该）在转换后将转换为 cgo 生成的代码。
由于这些工具通常运行的很好，所以出现的一些损失总会让人感到不安。
但是，gdb仍然有效地工作着。
总结（Summary）
总而言之，cgo 是一个具有局限性的伟大工具。
我们最近开始把一些低级操作转移到C++，这给了一些令人印象深刻的加速。
其他的尝试并没有带来更多地性能提升。
性能地表现不是还令人满意吗？