> 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. On Tuesday, April 18, 2023 at 7:56:07 PM UTC Ian Lance Taylor wrote: 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 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/bd93a76b-fd74-4641-ac7b-94652fdafa43n%40googlegroups.com.
