Why Does `map[string]string` and `map[string]bool` Show Similar Memory Usage in Go?

String Memory Usage in Golang

When optimizing a code using a map[string]string with values only being "A" or "B", the assumption might be that a map[string]bool would be more efficient due to its smaller value type. However, testing reveals that the memory usage for both maps is surprisingly the same.

Understanding unsafe.Sizeof()

To investigate this, unsafe.Sizeof() is utilized to measure the memory usage. However, it's essential to note that unsafe.Sizeof() only reports the "shallow" size of the data. In the case of maps, Go implements them using pointers. Therefore, unsafe.Sizeof(somemap) reports the size of the pointer, not the entire map's data.

String Memory Representation

Strings in Go are represented by a header consisting of a pointer to data and a length. The reflect.StringHeader type defines this structure:

type StringHeader struct {
    Data uintptr
    Len  int
}

Thus, unsafe.Sizeof(somemap) will only report the size of this header, which is independent of the string value.

Actual Memory Requirement for Maps

To obtain the actual memory usage for maps, it's important to consider the data they reference. In other words, len(str) int(unsafe.Sizeof(str)) provides a more accurate estimate.

Additional Considerations

Strings in Go store UTF-8 byte sequences in memory. The len() function reports the byte length, so the actual memory usage for a string can be approximated by:

stringSize := len(str) + int(unsafe.Sizeof(str))

It's also crucial to remember that slicing an existing string allocates a new backing array for the slice. Even if the original string is no longer referenced, the backing array will remain in memory to support the slice.

The above is the detailed content of Why Does `map[string]string` and `map[string]bool` Show Similar Memory Usage in Go?. For more information, please follow other related articles on the PHP Chinese website!