Answer to a question (stackoverflow) related to memory allocation for map[int]interface{} and map[int]struct{} in Golang.

Medium post: Memory Allocation and Performance in Golang Maps

The internal design of maps in Golang is highly optimized for performance and memory management. Maps keep track of keys and values that can hold pointers. If the entries in a bucket can't hold pointers, maps just create overflow buckets to avoid unnecessary overhead with GC, which results in more allocations (the case of map[int]struct{}).

We need to understand map initialization and map structure. Then, we will analyze the benchmarks.

There are two methods for map initialization:

• make(map[int]string) when we have no idea about how many entries will be added.
• make(map[int]string, hint) when we have an idea about how many entries will be added. hint is an estimate of the initial capacity.

Maps are mutable and they will grow on-demand, no matter which initialization method we choose. However, the second method pre-allocates memory for at least hint entries, which results in increased performance.

A map in Go is a hash table that stores its key/value pairs into buckets. Each bucket is an array that holds up to 8 entries. The default number of buckets is 1. Once the number of entries across each bucket reaches an average load of buckets (aka load factor), the map gets bigger by doubling the number of buckets. Every time a map grows, it allocates memory for the new-coming entries. In practice, every time the load of the buckets reaches 6.5 or more, the map grows.

Behind the scenes, a map is a pointer to the hmap struct. There is also the maptype struct, which holds some information about the type of the map. The source code for map can be found here:

https://github.com/golang/go/blob/master/src/runtime/map.go

Below you can find some insights on how to hack the map type and how to see a map growing:

• https://hackernoon.com/some-insights-on-maps-in-golang-rm5v3ywh
• https://play.golang.org/p/NaoC8fkmy9x

One important thing to note is that maps keep track of keys and values that can hold pointers. If the entries in a bucket can't hold any pointers, the bucket is marked as containing no pointers and maps just create overflow buckets (which means more memory allocations). This avoids unnecessary overhead with GC. See this comment in the mapextra struct (line 132) and this post for reference.

An empty struct struct{} has no fields and cannot hold any pointers. As a result, the buckets in the empty struct case will be marked as containing no pointers and we can expect more memory allocations for a map of type map[int]struct{} as it grows. On the other hand, interface{} can hold any values, including pointers. Map buckets keep track of the size of memory prefix holding pointers (ptrdata field, line 33) to decide if more overflow buckets will be created (map.go, line 265). Refer to this link to see the size of memory prefix holding all pointers for map[int]struct{} and map[int]interface{}.

The difference between the two benchmarks (Benchmark_EmptyStruct and Benchmark_Interface) is clear when we see the CPU profile. Benchmark_Interface does not have the (*hmap) createOverflow method that results in an additional memory allocation flow:

Benchmark_EmptyStruct CPU profile [png, svg]

Benchmark_Interface CPU profile [png, svg]

I customized the tests to pass the number of entries and the map's initial capacity (hint). Here are the results of the executions. Results are basically the same when there are few entries or when the initial capacity is greater than the number of entries. If you have many entries with an initial capacity of 0, you will get quite a different number for allocations.

There's nothing wrong with the benchmark methodology. It's all related to map optimization for performance and memory management. The benchmarks show the average value per iteration. Maps of type map[int]interface{} are slower because they suffer performance degradation when GC scans the buckets that can hold pointers. Maps of type map[int]struct{} use less memory because they, in fact, use less memory (Test_EmptyStructValueSize shows that struct{}{} has zero size). Despite nil being the zero value for interface{}, this type requires some space to store ANY value (Test_NilInterfaceValueSize test shows the size of an interface{} holding a nil value is not zero). Finally, the empty struct benchmark allocations are higher because the type map[int]struct{} requires more overflow buckets (for perfomance optimization) since its buckets don't hold any pointers.

(Benchmark_Interface only)

$ go test -cpuprofile interface.prof -benchmem -bench=^Benchmark_Interface$ -run=^$
$ go tool pprof interface.prof
(pprof) web mallocgc