Can you help me understand "fieldalignment: struct with 40 pointer bytes could be 8" ?

[floppyzedolfin]

Hello,
I get the following error on a struct:
"fieldalignment: struct with 40 pointer bytes could be 8"

For privacy reasons, I've renamed the fields of the struct with "anonymized" names

type MyStruct struct {
	FirstID  int64
	SecondID int64
	ThirdID  int64
	FourthID int64
	Name     string
}

When I run the golang-ci on this piece of code on travis, I get the following answer : fieldalignment: struct with 40 pointer bytes could be 8.

I don't see what's wrong with the order of the fields.

Travis is running go version go1.17.1 linux/amd64, golang-ci-lint version 1.42.1

Thank you for your kind help.

[cristaloleg]

Check this one 😉 https://itnext.io/structure-size-optimization-in-golang-alignment-padding-more-effective-memory-layout-linters-fffdcba27c61

[floppyzedolfin]

I don't get it. I'm running on a 64-bit architecture, so my string is going to cost 16 bytes. Each of the int64 is also going to use 8 bytes. The struct will align on chunks of 8 bytes : https://play.golang.org/p/W1L_LJ3HB_8

I can swap the order of the string and the int64s, but this doesn't change the alignment.

[floppyzedolfin]

For some reason I don't understand, moving the strings at the beginning of the struct rather than at the end (despite having no effect on the size of the struct itself, see link in cristaloleg's answer) did the trick.

[frederikhors]

Can you help me understand better this, @ldez and @floppyzedolfin?

I'm having this issue too with 1pkg/gopium#24.

[floppyzedolfin]

The only thing I could think of was "the only way this could use less bytes is by checking it against another architecture". But that's just guessing from me, and it isn't good enough an answer.

[frederikhors]

I think @1pkg found the answer here: 1pkg/gopium#24.

[mrol]

There is a tool to detect and fix this.

go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest
fieldalignment -fix <package_path>

[frederikhors]

Why isn't this in golangci-lint?

[butuzov]

Why isn't this in golangci-lint?

I guess because golangci-lint fixes code using internal mechanism, and not SuggestedFixes.

[zvonkok]

The only thing that bugs me is that fieldalignment will remove any comment on the struct fields. I haven't found any solution how to circumvent that by only readding the removed comments after reordering.

[xiegeo]

TLDR: All pointers should come first to optimize GC.

[dnswd]

This should be marked as answer

[MrwanBaghdad]

Check out this comment
fieldalignment does two kinds of analysis: struct sizes optimisations and optimisations for the garbage collector.

[danesparza]

Here is a pretty good explanation with a nice visual: https://medium.com/@sebassegros/golang-dealing-with-maligned-structs-9b77bacf4b97

The interesting bit:

Where we can see that padding (red squares) is added between the Doors and Brand fields in order to “complete” a word in memory, so the next field can start at an offset that’s multiple of a word size. At the previous example, we see that there are 11 bytes of padding that are just wasted, and this kind of waste is what the linters are warning us about.

In order to solve the problem from the example, we have to rearrange the struct’s fields in order to minimize the amount of padding bytes that are required for allocating the struct. Since the Doors and IsNew fields have a combined size less than a word size, they can be located right next to each other, reducing the padding bytes required from 11 to 3; so we end with something like this...

[ldez]

If you want to visualize the alignment: https://github.com/essentialkaos/aligo