потому что компилятор оптимизирует такие вещи, потому что знает семантику
https://github.com/golang/go/wiki/CompilerOptimizations Описано тут
Это на lookup (get) только. На set разумеется будет аллокация. func test(b []byte) { m := make(map[string]int) m[string(b)] = 10 // аллокация внутри slicebytetostring i := m[string(b)] // нет аллокации ибо незачем fmt.Println(i) } бенчи: BenchmarkSet-8 21428439 52.13 ns/op 3 B/op 1 allocs/op (почему только 3 я не понял) BenchmarkGet-8 87173618 14.36 ns/op 0 B/op 0 allocs/op 1. вообще я бы не сильно боялся аллокации, до 32Kb они сравнительно быстро проходят единственно assistgc мешает, было бы неплохо иметь функцию типа malloc которая выделит память без оказания помощи gc, но это надо мерять или метрики смотреть насколько сильно это мешает 2. если уж совсем прижмет я бы в сторону span смотрел, чтобы заранее по sizeclass выделять куски памяти, копировать туда слайсы и отдельной горутиной пополнять эти span
Обсуждают сегодня