鍍金池/ 問答/GO/ 關(guān)于golang中拷貝次數(shù)進而影響性能的問題

關(guān)于golang中拷貝次數(shù)進而影響性能的問題

先來看這么一個例子：

var aMap =map[int]int
aMap[1]=1

tmp:=aMap[1]
testMap1(tmp)
testMap2(aMap[1])

假設(shè)testMap1和testMap2的功能都是拿到參數(shù)之后打印一下參數(shù)值，那么到在他們打印前，testMap1完成這個動作進行了兩次拷貝，第一次拷貝是tmp:=aMap[1]，第二次拷貝是tmp到參數(shù)值。testMap2只需要一次拷貝。那么單從代碼性能來看，肯定不應(yīng)該用tmp:=aMap[1]這種方式去調(diào)用testMap。

那么我們再看go1.9中的sync.Map，我需要獲取map中的value需要調(diào)用其Load方法，那么這肯定會產(chǎn)生一次拷貝 即 tmp,_:=syncmap.Load(key)，而如果不用sync.Map，用普通Map，就可以像上面那樣直接 map[key]取出來用，這樣就少了一次拷貝。

不知道我這樣想的對不對，碰到value是那種很大的struct，拷貝的開銷應(yīng)該不小吧，有沒有什么好的解決這個拷貝開銷的思路，如果用sync.Map的話

回答
編輯回答
萢萢糖

你要取map中的值，無論是原生map還是sync.Map，難免會遇到值拷貝，除非你存進去的是一個指針/地址，大的“對象”可以存指針進去。
此外，sync.Map底層使用的是interface{}作為鍵值對，因此效率不是很高，可以參考一下gf框架的gmap包，以下是基準(zhǔn)測試結(jié)果：

john@johnstation:~/Workspace/Go/GOPATH/src/gitee.com/johng/gf/g/container/gmap$ go test *.go -bench=".*"
goos: linux
goarch: amd64
BenchmarkGmapSet-8            10000000           181 ns/op
BenchmarkSyncmapSet-8          5000000           366 ns/op
BenchmarkGmapGet-8            30000000            82.6 ns/op
BenchmarkSyncmapGet-8         20000000            95.7 ns/op
BenchmarkGmapRemove-8         20000000            69.8 ns/op
BenchmarkSyncmapRmove-8       20000000            93.6 ns/op
PASS
ok      command-line-arguments    27.950s
2017年4月25日 14:28
編輯回答
墨小白

做優(yōu)化時, 應(yīng)該使用性能分析工具而不單純靠主觀想法.

比如, 這樣做 map 與 sync.Map 的對比測試

// 代碼僅做演示用途
// 執(zhí)行 "go test -bench xx.go"
package main

import (
    "sync"
    "testing"
)

func Benchmark_map(b *testing.B) {
    m := make(map[int]int)
    for i := 0; i < b.N; i++ {
        m[1] = 1
    }
}

func Benchmark_sync_map(b *testing.B) {
    var m sync.Map
    for i := 0; i < b.N; i++ {
        m.Store(1, 1)
    }
}

參考

  1. Profiling Go Programs, https://blog.golang.org/profi...
  2. A Quick Guide to Go's Assembler, https://golang.org/doc/asm
2017年10月14日 05:30
編輯回答
伐木累

后經(jīng)證明，兩種方式?jīng)]區(qū)別，編譯器會進行優(yōu)化

2018年5月26日 20:58