CODEWITHSUNDEEP
performancego
srini
srini

Reputation: 1208

in golang, is there any performance difference between maps initialized using make vs {}

as we know there are two ways to initialize a map (as listed below). I'm wondering if there is any performance difference between the two approaches.

var myMap map[string]int

then

myMap = map[string]int{}

vs 

myMap = make(map[string]int)

Upvotes: 7

Views: 2048

Answers (3)

Oleksandr Pryimak
Oleksandr Pryimak

Reputation: 1581

A year ago I actually stumped on the fact that using make with explicitly allocated space is better then using map literal if your values are not static

So doing

return map[string]float {
    "key1": SOME_COMPUTED_ABOVE_VALUE,
    "key2": SOME_COMPUTED_ABOVE_VALUE,
    // more keys here
    "keyN": SOME_COMPUTED_ABOVE_VALUE,
}

is slower then

// some code above
result := make(map[string]float, SIZE) // SIZE >= N
result["key1"] = SOME_COMPUTED_ABOVE_VALUE
result["key2"] = SOME_COMPUTED_ABOVE_VALUE
// more keys here
result["keyN"] = SOME_COMPUTED_ABOVE_VALUE
return result

for N which are quite big (N=300 in my use case). The reason is the compiler fails to understand that one needs to allocate at least N slots in the first case.

I wrote a blog post about it https://trams.github.io/golang-map-literal-performance/ and I reported a bug to the community https://github.com/golang/go/issues/43020

As of golang 1.17 it is still an issue.

Upvotes: 0

Grzegorz Żur
Grzegorz Żur

Reputation: 49181

When allocating empty maps there is no difference but with make you can pass second parameter to pre-allocate space in map. This will save a lot of reallocations when maps are being populated.

Benchmarks

package maps

import "testing"

const SIZE = 10000

func fill(m map[int]bool, size int) {
    for i := 0; i < size; i++ {
        m[i] = true
    }
}

func BenchmarkEmpty(b *testing.B) {
    for n := 0; n < b.N; n++ {
        m := make(map[int]bool)
        fill(m, SIZE)
    }
}

func BenchmarkAllocated(b *testing.B) {
    for n := 0; n < b.N; n++ {
        m := make(map[int]bool, 2*SIZE)
        fill(m, SIZE)
    }
}

Results

go test -benchmem -bench .
BenchmarkEmpty-8             500       2988680 ns/op      431848 B/op        625 allocs/op
BenchmarkAllocated-8        1000       1618251 ns/op      360949 B/op         11 allocs/op

Upvotes: 4

John Weldon
John Weldon

Reputation: 40759

On my machine they appear to be about equivalent.

You can easily make a benchmark test to compare. For example:

package bench

import "testing"

var result map[string]int

func BenchmarkMakeLiteral(b *testing.B) {
        var m map[string]int
        for n := 0; n < b.N; n++ {
                m = InitMapLiteral()
        }
        result = m
}

func BenchmarkMakeMake(b *testing.B) {
        var m map[string]int
        for n := 0; n < b.N; n++ {
                m = InitMapMake()
        }
        result = m
}

func InitMapLiteral() map[string]int {
        return map[string]int{}
}

func InitMapMake() map[string]int {
        return make(map[string]int)
}

Which on 3 different runs yielded results that are close enough to be insignificant:

First Run

$ go test -bench=.
testing: warning: no tests to run
PASS
BenchmarkMakeLiteral-8  10000000               160 ns/op
BenchmarkMakeMake-8     10000000               171 ns/op
ok      github.com/johnweldon/bench     3.664s

Second Run

$ go test -bench=.
testing: warning: no tests to run
PASS
BenchmarkMakeLiteral-8  10000000               182 ns/op
BenchmarkMakeMake-8     10000000               173 ns/op
ok      github.com/johnweldon/bench     3.945s

Third Run

$ go test -bench=.
testing: warning: no tests to run
PASS
BenchmarkMakeLiteral-8  10000000               170 ns/op
BenchmarkMakeMake-8     10000000               170 ns/op
ok      github.com/johnweldon/bench     3.751s

Upvotes: 5

Related Questions