Golang 1.9 新特性预览：Logging、interfaces 和 allocation

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