該文翻譯自：http://commaok.xyz/post/interface-allocs/
幾個(gè)星期前咖熟，Peter Bourgon在golang-dev開了一個(gè)關(guān)于標(biāo)準(zhǔn)化日志記錄的帖子号坡。 日志很常用耕捞，因此性能很快提升逃沿。 go-kit日志包使用結(jié)構(gòu)化日志凯亮，接口如下：
typeLoggerinterface {
Log(keyvals ...interface{}) error
}
調(diào)用代碼：
logger.Log("transport","HTTP","addr", addr,"msg","listening")
請注意，進(jìn)入日志調(diào)用的所有內(nèi)容都將轉(zhuǎn)換為interface{}柠并。 這意味著它分配了不少內(nèi)存富拗。
與另一個(gè)結(jié)構(gòu)化日志庫zap進(jìn)行比較。 Zap為了避免內(nèi)存分配和interface{}使用瘟栖，導(dǎo)致了更丑的API：
logger.Info("Failed to fetch URL.",
zap.String("url", url),
zap.Int("attempt", tryNum),
zap.Duration("backoff", sleepFor),
)
logger.Info的參數(shù)是logger.Field谅阿。 logger.Field是一種union-ish結(jié)構(gòu)酬滤，包括一個(gè)string盯串，一個(gè)int和一個(gè)interface{}戒良。 因此，接口不必用來傳遞最常見的值几缭。
關(guān)于logging先討論到這里沃呢。接下來討論為什么將具體值轉(zhuǎn)換為interface{}時(shí)有內(nèi)存分配？
interface{}表示為一個(gè)類型指針和一個(gè)值指針某抓。 Russ Cox寫了一篇文章解釋這個(gè)問題惰瓜。
他的文章稍微有些過時(shí)了。但是他指出了一個(gè)優(yōu)化方式：當(dāng)值小于等于指針大小時(shí)备禀，我們可以將值直接放入第二個(gè)字段流强。 然而打月，隨著并發(fā)垃圾收集的出現(xiàn)蚕捉，該優(yōu)化被取消了。 現(xiàn)在接口中的第二個(gè)字段總是一個(gè)指針秘通。
考慮如下代碼：
fmt.Println(1)
在Go 1.4之前敛熬，這段代碼沒有內(nèi)存分配，因?yàn)橹?可以直接放入第二個(gè)字段话原。
也就是說，編譯器這樣處理：
fmt.Println({int,1})
其中{typ涉馅，val}表示接口中的兩個(gè)字段黄虱。
從Go 1.4開始，這個(gè)代碼開始分配內(nèi)存晤揣，因?yàn)?不是指針默勾，第二個(gè)字必須包含一個(gè)指針母剥。 所以，編譯器+運(yùn)行時(shí)這樣處理：
i:=new(int)// allocates!
*i=1fmt.Println({int, i})
優(yōu)化內(nèi)存分配的第一點(diǎn)是確保當(dāng)生成的接口沒有逃逸习霹。 在這種情況下炫隶，臨時(shí)值可以放在棧上而不是堆上。 使用我們上面的示例代碼：
i :=new(int)// now doesn't allocate, as long as e doesn't escape*i =1vareinterface{} = {int, i}// do things with e that don't make it escape
不幸的是煞檩，許多interface{}都會(huì)逃逸栅贴，包括在調(diào)用fmt.Println和我們上面的日志示例中使用的interface{}。
幸運(yùn)的是凝赛，Go 1.9將帶來更多的優(yōu)化坛缕，部分優(yōu)化受logging的啟發(fā)赚楚。
第一個(gè)優(yōu)化是不再將常量轉(zhuǎn)換為接口。 所以fmt.Println（1）將不再分配內(nèi)存宠页。 編譯器將值1放在只讀全局變量中，大致如下：
variint =1// at the top level, marked as readonly
fmt.Println({int, &i})
因?yàn)槌Ａ渴遣豢勺兊姆俅蹋悦看谓涌谵D(zhuǎn)換都會(huì)獲得相同的值门烂，包括遞歸和并發(fā)調(diào)用。
這是由loggin直接啟發(fā)的蔓姚。 在結(jié)構(gòu)化日志中慨丐，許多參數(shù)是常量。 go-kit例子：
logger.Log("transport","HTTP","addr", addr,"msg","listening")
此代碼將從6次內(nèi)存分配減少到1次备闲，因?yàn)槠渲形鍌€(gè)參數(shù)是常量字符串捅暴。
第二個(gè)新的優(yōu)化是不將bool和byte轉(zhuǎn)換為接口蓬痒。 這種優(yōu)化的工作原理是添加一個(gè)名為staticbytes的全局[256]字節(jié)數(shù)組，其中所有b的staticbytes [b] = b狱掂。 當(dāng)編譯器想要將bool或uint8或其他單字節(jié)值放入接口時(shí)亲轨，它會(huì)使用一個(gè)指向該數(shù)組的指針代替。 那是：
var staticbytes [256]byte = {0,1,2,3,4,5, ...}
i := uint8(1)
fmt.Println({int, &staticbytes[i]})
第三個(gè)新的優(yōu)化建議仍在review希柿，這個(gè)優(yōu)化是轉(zhuǎn)換常見的零值優(yōu)化养筒。 它適用于整數(shù)晕粪，浮點(diǎn)數(shù)渐裸，字符串和切片装悲。 此優(yōu)化通過在運(yùn)行時(shí)檢查值是否為0（或“”或nil）工作诀诊。 如果是零值阅嘶，它使用指向現(xiàn)有的大塊零內(nèi)存的指針，而不是分配一些內(nèi)存并將其置零抡蛙。
如果一切順利魂迄，Go 1.9應(yīng)該在接口轉(zhuǎn)換期間消除相當(dāng)數(shù)量的內(nèi)存分配捣炬。但它不會(huì)消除所有的內(nèi)存分配，這使得仍然存在以上討論的性能問題浴捆。
選擇API需要考慮性能稿械。這也是為什么io.Reader要求/允許調(diào)用者使用自己的緩沖區(qū)。
性能在很大程度上是設(shè)計(jì)實(shí)現(xiàn)的結(jié)果页眯。我們已經(jīng)看到在這篇文章中厢呵，接口的實(shí)現(xiàn)細(xì)節(jié)可以大大改善內(nèi)存分配。
很多設(shè)計(jì)和實(shí)現(xiàn)決策取決于人們寫什么樣的代碼碌奉。編譯器和運(yùn)行時(shí)的作者想要優(yōu)化實(shí)際的寒砖，通用的代碼哩都。例如，在Go 1.4中咐汞，決定將接口值保持在兩個(gè)字而不是將它們改為三個(gè)，這使得調(diào)用fmt.Println（1）分配額外內(nèi)存几晤。
由于人們編寫的代碼通常被他們使用的API塑造植阴，所以這是一種有機(jī)的反饋循環(huán)，這也是有趣的墙贱，有挑戰(zhàn)性的管理热芹。
如果你設(shè)計(jì)一個(gè)API，并擔(dān)心性能問題惨撇，不要忘記現(xiàn)有的編譯器和運(yùn)行時(shí)實(shí)際做了什么或者他們可以做什么伊脓。編寫當(dāng)下的代碼，但設(shè)計(jì)未來的API魁衙。
