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. On Tuesday, April 18, 2023 at 7:54:17 PM UTC+2 Def Ceb wrote: > 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? > > -- 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/bc9c3759-0a7a-441b-a1a1-e762a738ce34n%40googlegroups.com.
