類型斷言將涉及對(duì) runtime.assertE2T 或 runtime.assertE2I 的調(diào)用（您可以看到匯編代碼）。package mainimport ( "fmt" "time")type I interface { echo()}type A struct{}func (a *A) echo() {}type testfn func()func run(f testfn) { ts := time.Now() f() te := time.Now() fmt.Println(te.Sub(ts))}func testE2T() { var i interface{} = new(A) for a := 0; a < 500000000; a++ { _ = i.(*A) }}func testE2I() { var i interface{} = new(A) for a := 0; a < 500000000; a++ { _ = i.(I) }}func main() { fmt.Println("testE2I:") run(testE2I) fmt.Println("testE2T:") run(testE2T)}結(jié)果：testE2I:11.065225934stestE2T:5.720773381s似乎類型斷言比 C 中的指針轉(zhuǎn)換慢？怎么解釋？而且奇怪的是，當(dāng)我使用gccgo運(yùn)行相同的程序時(shí)，會(huì)導(dǎo)致內(nèi)存不足錯(cuò)誤。gccgo 在 gc 中有一些限制嗎？
1 回答
慕標(biāo)5832272
TA貢獻(xiàn)1966條經(jīng)驗(yàn) 獲得超4個(gè)贊
我不太清楚你的主要問題是什么，但我會(huì)盡量回答你提出的問題。
似乎類型斷言比 C 中的指針轉(zhuǎn)換慢？
是的。類型斷言在運(yùn)行時(shí)需要是安全的，因此它們需要執(zhí)行許多檢查。接口到接口斷言更糟糕，因?yàn)槟€需要確保類型實(shí)現(xiàn)了接口。
話雖如此，他們絕對(duì)可以表現(xiàn)得更好。事實(shí)上，這是您在 Go 1.4.2 上的基準(zhǔn)測試結(jié)果的比較。與 Go 1.5 的最新開發(fā)版本對(duì)比：
轉(zhuǎn)到 1.4.2：
testE2I: 10.014922955s, testE2T: 4.465621814s轉(zhuǎn)到 1.5 開發(fā)：
testE2I: 7.201485053s, testE2T: 287.08346ms
它現(xiàn)在快了十倍以上，而且 Go 1.6 的新 SSA 后端可能會(huì)帶來更好的優(yōu)化。
而且奇怪的是，當(dāng)我使用gccgo運(yùn)行相同的程序時(shí)，會(huì)導(dǎo)致內(nèi)存不足錯(cuò)誤。gccgo 在 gc 中有一些限制嗎？
我猜這是 gccgo 缺乏逃逸分析，但我可能錯(cuò)了。我實(shí)際上能夠在我的機(jī)器上使用 gccgo 運(yùn)行基準(zhǔn)測試，但它消耗了大約 9 GB 的 RAM，這很正常。我很確定提交一個(gè)問題不會(huì)有什么壞處。無論如何，這是結(jié)果-O3：
gccgo：
testE2I: 30.405681s, testE2T: 1.734307s
在具體類型上更快，但在接口到接口斷言時(shí)要慢得多。
- 1 回答
- 0 關(guān)注
- 243 瀏覽
添加回答
舉報(bào)
0/150
提交
取消