1.9 新特性预览:Logging, interfaces, and allocation

方圆 · · 1711 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

该文翻译自: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。


有疑问加站长微信联系(非本文作者)

本文来自:微信公众平台

感谢作者:方圆

查看原文:1.9 新特性预览:Logging, interfaces, and allocation

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

1711 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传