Size Optimization Tricks (2022)

> but I don’t understand why these extra paddings are present and why one is gone

In the example from the article, the "s_arc" member is a pointer (8 bytes) and requires an alignment at an 8-byte boundary. The ints are 4 bytes in size. The whole struct needs to be aligned on an 8-byte boundary, in order to preserve the alignment requirements of the pointers. The trailing "s_accept" member requires additional padding to make the size of the struct divisible by 8, and that would preserve the alignment of an eventual second adjacent struct, when having an array of these structs.

I suspect it depends upon your niche/field, there are certainly times when I've done assembly coding for production. Although I admit these days most of my assembly-coding is for retro-uses.

> I don’t understand why these extra paddings are present and why one is gone. Even with pragma pack 8, should not it be only one padding?

If you're referring to `__pad2` in the example, that trailing padding is there to ensure that the size of the struct is a multiple of its alignment, which is 8, so that if there's a contiguous span of those structures, each instance after the first one will remained properly aligned. Without `__pad2`, that struct would be 36-bytes, which would cause every other instance in an array/contiguous-span to be aligned on 4 bytes instead of 8.

One day you might have to patch a binary with a hex editor. For reason or another.

It's all extremely clever, but is it useful?

Not to belittle Justine's achievements, but the role of the most important software developer probably goes to the maintainer of some hugely important infrastructure project that we barely know about.

https://xkcd.com/2347/

If Justine didn't optimize struct padding, binaries would be a bit larger, but software would keep working. However, if a trivial library like left-pad is gone, it triggers global chaos of such monumental proportions that it warrants its own Wikipedia article https://en.wikipedia.org/wiki/Npm_left-pad_incident

Or there might be some unsung hero responsible for fixing a year 2038 bug in a bunch of ICBMs who prevented worldwide nuclear annihilation (or who caused it, if you have a more pessimistic view of the future).

Knuth, Bellard, Tunney.

clang-tidy has an extension to do just that: https://clang.llvm.org/extra/clang-tidy/checks/altera/struct... -- I think there are other clang-tidy padding-related checks that apply here as well, iirc.

Also, not what you asked but certainly related, some lower-language levels (not just jit languages) can and do automatically re-arrange struct members (when not optionally fixed); e.g. by default rust will rearrange members as needed to optimize padding.

Bolt can do quite a lot of optimizations: https://github.com/llvm/llvm-project/tree/main/bolt

clang has -Wpadded to warn about added alignment padding, but it's really noisy.

> while there's also a push to statically link everything

could you elaborate? who is pushing and what?

dynamic linking has it pitfalls, often it's a pain, but it has big big profits as well.