Reduce memory usage via reduced padding?

[Def Ceb]

Hello.

This is a request for comments on an idea I had.

While working on a personal project, I noticed that quite a few structs in the standard library, exported or otherwise, could have their memory footprint reduced by simply reordering their members so that padding required for alignment is reduced or even eliminated.

This can be in exported and unexported structs, and in both exported and unexported fields.

Examples as of Go 1.20.3, on an amd64 host:

• moving the member h of the unexported struct crypto/sha1.digest to the end would remove 4 bytes of padding between x and nx
  

• moving the unexported minInputLen field of the regexp.Regexp struct to right after matchcap will remove 6 bytes of padding
• The Typeflag member of archive/tar.Header could be moved to the end of the struct, removing 7 bytes of padding
  

Instances similar to the first two examples should be fairly frictionless, only affecting code that makes unsafe assumptions about standard library internals.

Examples of the third would, at the very least, break unkeyed struct literals, either at compile-time or silently at run-time, depending on the types in use and whether the instantiation uses a compatible literal.

While implementing the third example does not seem to go against the Go 1 compatibility promise, it would seem like a fairly unpopular change if it caused large swathes of code utilizing unkeyed struct literals to stop compiling or, worse, break silently, and unless using them is prohibited at some point (at least for non-locally-defined structs), it'll probably be avoided. As far as I can tell, the status is similar for Go assembly.

As a benefit, this would lead to some small reductions in memory usage per instance of many structs, potentially leading to reduced need to grow the stack of threads. Though there are arguments that could be made against this as well, such as that some structs may contain multiple "groups" of data (which are not split up into multiple structs, for whatever reason) which shouldn't be split up, or that it could cause too much churn for too little benefit (I have not implemented nor benchmarked this at the moment), or that this is good, but it should be handled in the compiler instead.

I already made something to automatically generate a list of structs in the standard library which have padding, based on my project.

1. Would a pull request with struct reordering to reduce padding be welcomed?
2. Is there any chance of a policy of "try to avoid padding, if practical" being put in place for future additions to the standard library?
3. What about the gc compiler reordering struct member ordering at compile-time for the same effect, and in third-party code as well?
   

[TheDiveO]

The standard libraries in several parts define and also use structs where the field ordering and padding is crucial as they are shared with operating system functions. Trying to rearrange fields in 3rd party apllications would immediately workhorses like Docker container engine, with associated as well as independent modules for low-level networking configuration and communication, communication with netfilter system functions on freebsd, linux, and many more things.

To rephrase a well-meant warning from a manager: there are better ways to become prominent.

[TheDiveO]

...would immediately negatively affect workhorses...

[Def Ceb]

True, having it as a general compiler optimization and fiddling with many structs dealing with lower-level things are off-limits.

And serialization via e.g encoding/binary is also a reason to avoid touching public fields.

[Ian Lance Taylor]

On Tue, Apr 18, 2023 at 10:54 AM Def Ceb <mikk....@gmail.com> wrote:
>
> While working on a personal project, I noticed that quite a few structs in the standard library, exported or otherwise, could have their memory footprint reduced by simply reordering their members so that padding required for alignment is reduced or even eliminated.
> This can be in exported and unexported structs, and in both exported and unexported fields.

FYI, there is an existing tool that can detect structs where fields
could be rearranged.

> go run golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest regexp
/home/iant/go/src/regexp/backtrack.go:37:15: struct with 160 pointer
bytes could be 152
/home/iant/go/src/regexp/exec.go:24:12: struct with 16 pointer bytes could be 8
/home/iant/go/src/regexp/exec.go:38:14: struct with 224 pointer bytes
could be 216
/home/iant/go/src/regexp/regexp.go:86:13: struct of size 160 could be 152
/home/iant/go/src/regexp/all_test.go:430:17: struct with 56 pointer
bytes could be 48
/home/iant/go/src/regexp/all_test.go:482:20: struct with 48 pointer
bytes could be 40

> The Typeflag member of archive/tar.Header could be moved to the end of the struct, removing 7 bytes of padding

I don't think that one helps, as struct sizes are always increased to
be a multiple of the required struct alignment.

> Examples of the third would, at the very least, break unkeyed struct literals, either at compile-time or silently at run-time, depending on the types in use and whether the instantiation uses a compatible literal.
> While implementing the third example does not seem to go against the Go 1 compatibility promise, it would seem like a fairly unpopular change if it caused large swathes of code utilizing unkeyed struct literals to stop compiling or, worse, break silently, and unless using them is prohibited at some point (at least for non-locally-defined structs), it'll probably be avoided. As far as I can tell, the status is similar for Go assembly.

In general the Go 1 compatibility guarantee permits us to rearrange
struct fields, and that is helped because "go vet" will warn about
using an unkeyed struct literal for a struct defined in a different
package.

> Would a pull request with struct reordering to reduce padding be welcomed?

Well, maybe. Where it makes sense. For many structs the size really
doesn't matter, and the order of the fields makes the struct
definition easier to read. If there is a real performance difference,
then, sure.

> Is there any chance of a policy of "try to avoid padding, if practical" being put in place for future additions to the standard library?

Where it doesn't hurt readability, sure.

> What about the gc compiler reordering struct member ordering at compile-time for the same effect, and in third-party code as well?

Historically it's hard for compilers to know whether such field
rearrangement is safe. The benefit you get, which is usually small,
is not worth the slowdown in compile time. Better to follow the path
you are already on: use a tool to find cases where it might make a
difference.

Ian

[Def Ceb]

> FYI, there is an existing tool that can detect structs where fields
> could be rearranged.

Interesting, I hadn't run into that before.

> I don't think that one helps, as struct sizes are always increased to

> be a multiple of the required struct alignment.

Ah, this is true. I was working off of go.dev/s/regabi and it seemed to imply that there's a lot less padding at the end of a struct.

> If there is a real performance difference, then, sure.

Fair enough, I'll try and check.