该文翻译自：interface-allocs
几个星期前，Peter Bourgon在golang-dev开了一个关于标准化日志记录的帖子。 日志很常用，因此性能很快提升。 go-kit日志包使用结构化日志，接口如下：
type Logger interface {
Log(keyvals ...interface{}) error
}调用代码：
logger.Log("transport", "HTTP", "addr", addr, "msg", "listening")请注意，进入日志调用的所有内容都将转换为interface{}。 这意味着它分配了不少内存。
与另一个结构化日志库zap进行比较。 Zap为了避免内存分配和interface{}使用，导致了更丑的API：
logger.Info("Failed to fetch URL.",
zap.String("url", url),
zap.Int("attempt", tryNum),
zap.Duration("backoff", sleepFor),
)logger.Info的参数是logger.Field。 logger.Field是一种union-ish结构，包括一个string，一个int和一个interface{}。 因此，接口不必用来传递最常见的值。
关于logging先讨论到这里。接下来讨论为什么将具体值转换为interface{}时有内存分配？
interface{}表示为一个类型指针和一个值指针。 Russ Cox写了一篇文章解释这个问题。
他的文章稍微有些过时了。但是他指出了一个优化方式：当值小于等于指针大小时，我们可以将值直接放入第二个字段。 然而，随着并发垃圾收集的出现，该优化被取消了。 现在接口中的第二个字段总是一个指针。
考虑如下代码：
fmt.Println(1)在Go 1.4之前，这段代码没有内存分配，因为值1可以直接放入第二个字段。
也就是说，编译器这样处理：
fmt.Println({int, 1})其中{typ，val}表示接口中的两个字段。
从Go 1.4开始，这个代码开始分配内存，因为1不是指针，第二个字必须包含一个指针。 所以，编译器+运行时这样处理：
i := new(int) // allocates!
*i = 1fmt.Println({int, i})优化内存分配的第一点是确保当生成的接口没有逃逸。 在这种情况下，临时值可以放在栈上而不是堆上。 使用我们上面的示例代码：
i := new(int) // now doesn't allocate, as long as e doesn't escape*i = 1var e interface{} = {int, i}// do things with e that don't make it escape不幸的是，许多interface{}都会逃逸，包括在调用fmt.Println和我们上面的日志示例中使用的interface{}。
幸运的是，Go 1.9将带来更多的优化，部分优化受logging的启发。
第一个优化是不再将常量转换为接口。 所以fmt.Println（1）将不再分配内存。 编译器将值1放在只读全局变量中，大致如下：
var i int = 1 // at the top level, marked as readonly
fmt.Println({int, &i})因为常量是不可变的，所以每次接口转换都会获得相同的值，包括递归和并发调用。
这是由loggin直接启发的。 在结构化日志中，许多参数是常量。 go-kit例子：
logger.Log("transport", "HTTP", "addr", addr, "msg", "listening")此代码将从6次内存分配减少到1次，因为其中五个参数是常量字符串。
第二个新的优化是不将bool和byte转换为接口。 这种优化的工作原理是添加一个名为staticbytes的全局[256]字节数组，其中所有b的staticbytes [b] = b。 当编译器想要将bool或uint8或其他单字节值放入接口时，它会使用一个指向该数组的指针代替。 那是：
var staticbytes [256]byte = {0, 1, 2, 3, 4, 5, ...}
i := uint8(1)
fmt.Println({int, &staticbytes[i]})第三个新的优化建议仍在review，这个优化是转换常见的零值优化。 它适用于整数，浮点数，字符串和切片。 此优化通过在运行时检查值是否为0（或“”或nil）工作。 如果是零值，它使用指向现有的大块零内存的指针，而不是分配一些内存并将其置零。
如果一切顺利，Go 1.9应该在接口转换期间消除相当数量的内存分配。但它不会消除所有的内存分配，这使得仍然存在以上讨论的性能问题。
选择API需要考虑性能。这也是为什么io.Reader要求/允许调用者使用自己的缓冲区。
性能在很大程度上是设计实现的结果。我们已经看到在这篇文章中，接口的实现细节可以大大改善内存分配。
很多设计和实现决策取决于人们写什么样的代码。编译器和运行时的作者想要优化实际的，通用的代码。例如，在Go 1.4中，决定将接口值保持在两个字而不是将它们改为三个，这使得调用fmt.Println（1）分配额外内存。
由于人们编写的代码通常被他们使用的API塑造，所以这是一种有机的反馈循环，这也是有趣的，有挑战性的管理。
如果你设计一个API，并担心性能问题，不要忘记现有的编译器和运行时实际做了什么或者他们可以做什么。编写当下的代码，但设计未来的API。
有疑问加站长微信联系（非本文作者）
