...would immediately *negatively affect* workhorses... On Tuesday, April 18, 2023 at 8:26:27 PM UTC+2 TheDiveO wrote:
> 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/bd28cd16-aa9d-4aa9-b93b-64acfa965ed3n%40googlegroups.com.
