Optimising datastructure/word alignment padding in golang

Similar to what I've learned in C++, I believe it's the padding that causes a difference in the size of instances of both structs.

type Foo struct {
    w byte //1 byte
    x byte //1 byte
    y uint64 //8 bytes
}
type Bar struct {
    x byte //1 byte
    y uint64 //8 bytes
    w byte// 1 byte
}
func main() {
    fmt.Println(runtime.GOARCH)
    newFoo := new(Foo)
    fmt.Println(unsafe.Sizeof(*newFoo))
    newBar := new(Bar)
    fmt.Println(unsafe.Sizeof(*newBar))
}

Output:

amd64
16
24

• Is there a rule of thumb to follow when defining struct members? (like ascending/descending order of size of types)
• Is there a compile time optimisation which we can pass, that can automatically take care of this?
• Or shouldn't I be worried about this at all?

Currently there's no compile-time optimisation; the values are padded to 8 bytes on x64.

You can manually arrange structs to optimally utilise space; typically by going from larger types to smaller; 8 consecutive byte fields for example, will only use 8 bytes, but a single byte would be padded to an 8 byte alignment, consider this: https://play.golang.org/p/0qsgpuAHHp

package main

import (
	"fmt"
	"unsafe"
)

type Compact struct {
	a, b                   uint64
	c, d, e, f, g, h, i, j byte
}

// Larger memory footprint than "Compact" - but less fields!
type Inefficient struct {
	a uint64
	b byte
	c uint64
	d byte
}

func main() {
	newCompact := new(Compact)
	fmt.Println(unsafe.Sizeof(*newCompact))
	newInefficient := new(Inefficient)
	fmt.Println(unsafe.Sizeof(*newInefficient))
}

If you take this into consideration; you can optimise the memory footprint of your structs.

> Or shouldn't I be worried about this at all?

Yes you should.
This is also called mechanical sympathy (see this Go Time podcast episode), so it also depends on the hardware architecture you are compiling for.

See as illustration:

• "The day byte alignment came back to bite me" (January 2014)
• "On the memory alignment of Go slice values" (July 2016)

> The values in Go slices are 16-byte aligned. They are not 32 byte aligned.
Go pointers are byte-aligned.

It depends on type of application that you are developing and on usage of those structures. If application needs to meet some memory/performance criteria you definitely should care about memory alignment and paddings, but not only - there is nice article https://www.usenix.org/legacy/publications/library/proceedings/als00/2000papers/papers/full_papers/sears/sears_html/index.html that highlights theme of optimal CPU caches usage and correlation between struct layouts and performance. It highlights cache line alignment, false sharing, etc.

Also there is a nice golang tool https://github.com/1pkg/gopium that helps to automate those optimizations, check it out!

Some guideline

> To minimize the number of padding bytes, we must lay out the fields from
the highest allocation to lowest allocation.

One exception is an empty structure

As we know the size of empty is zero

type empty struct {
	a struct{}
}

Following the common rule above, we may arrange the fields of structure as below

type E struct {
	a int64
	b int64
	c struct{}
}

However, the size of E is 24,

When arrange the fields of structure as

type D struct {
    b struct{}
	a int64
	c int64
}

The size of D is 16, refer to https://go.dev/play/p/ID_hN1zwIwJ

IMO, it is better to use tools that help us to automate structure alignment optimizations

• aligncheck — https://gitlab.com/opennota/check
• maligned — <del>https://github.com/mdempsky/maligned</del>, the original maligned is deprecated. Use https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/fieldalignment
• golang clint
  • you just need to enable ‘maligned’ in the ‘golangci-lint’ settings.
    Example, from the configuration file.golangci.example.yml

linters-settings:
  maligned:
      # print struct with more effective memory layout or not, false by default
      suggest-new: true