我的用例是通過網絡傳輸一組成員（整數），所以我們采用增量編碼，在接收端我們解碼并將整個列表作為映射，map[string]struct{} 復雜度為 O(1)用于會員檢查。我面臨的問題是，對于 200 萬個整數，成員的實際大小僅為 15MB，但堆中映射的大小為 100+MB。似乎 Go 的實際地圖實現不適合大型地圖。由于它是一個客戶端 SDK，我不想對可用內存產生太大影響，并且可能有多個這樣的組需要在內存中保存很長時間——大約 1 周。為此，Go 中是否有更好的替代 DS？type void struct{}func ToMap(v []int64) map[string]void { out := map[string]void{} for _, i := range v { out[strconv.Itoa(int(i))] = void{} } return out}
1 回答
神不在的星期二
TA貢獻1963條經驗 獲得超6個贊
這是一種更節省內存的地圖形式：
type void struct{}
func ToMap(v []int64) map[int64]void {
m := make(map[int64]void, len(v))
for _, i := range v {
m[i] = void{}
}
return m
}
Go 映射針對整數鍵進行了優化。通過給出確切的地圖大小作為提示來優化地圖分配。
Astring有一個隱式指針，它會使垃圾收集器 (gc) 每次掃描時都遵循該指針。
這是 200 萬個偽隨機整數的 Go 基準測試：
package main
import (
"math/rand"
"strconv"
"testing"
)
type void struct{}
func ToMap1(v []int64) map[string]void {
out := map[string]void{}
for _, i := range v {
out[strconv.Itoa(int(i))] = void{}
}
return out
}
func ToMap2(v []int64) map[int64]void {
m := make(map[int64]void, len(v))
for _, i := range v {
m[i] = void{}
}
return m
}
var benchmarkV = func() []int64 {
v := make([]int64, 2000000)
for i := range v {
v[i] = rand.Int63()
}
return v
}()
func BenchmarkToMap1(b *testing.B) {
b.ReportAllocs()
b.ResetTimer()
for N := 0; N < b.N; N++ {
ToMap1(benchmarkV)
}
}
func BenchmarkToMap2(b *testing.B) {
b.ReportAllocs()
b.ResetTimer()
for N := 0; N < b.N; N++ {
ToMap2(benchmarkV)
}
}
輸出：
$ go test tomap_test.go -bench=.
BenchmarkToMap1-4 2 973358894 ns/op 235475280 B/op 2076779 allocs/op
BenchmarkToMap2-4 10 188489170 ns/op 44852584 B/op 23 allocs/op
$
- 1 回答
- 0 關注
- 129 瀏覽
添加回答
舉報
0/150
提交
取消