> That said, some structs may have a smaller size, but for efficiency, the Go runtime will allocate them in the same size class, then those structs are not considered sloppy:

It's not for efficiency, per se. As in C, to support arrays of structs all structs are padded so their size is a multiple of the strictest (largest) alignment of any of its members. If the example struct described above were 24 bytes instead of 32, then the second element of an array of those structs wouldn't be properly aligned for any of its uint64 or pointer members. On architectures that require aligned loads and stores that's not an efficiency optimization, but required for correctness.

Looking at this from a performance point of view, I think this could be useful with the addition of some tracing capability.

What I mean is, reducing the size of a barely-used struct isn't worth the effort, but reduction of a key struct in a critical region, or a large bloated array of structs could be very useful.

So some measure of: possible reduction (which structslop provides), 'hotness', and total memory usage, would make this a killer feature.

From my bare-metal days we used to manually rearrange structs or use them packed, but it'd be great to have a tool that could attach to your codebase and do that analysis for you.

This is fascinating... but I do believe there’s a reason that those fields are not re-arranged by the go compiler already, which is to preserve C ABI Compatibility. I doubt that’s worth it in most cases, though. Does it still preserve them in “pure” mode?

Blog post: https://medium.com/orijtech-developers/efficient-struct-pack...

You could do this whole analysis (and changes if you wanted to) at compile time in D. Not that you should (they're aligned like they are for a reason)