Memory Alignment and Padding

CPUs read memory most efficiently when a value's address is a multiple of its own size — a 4-byte int at an address divisible by 4, an 8-byte double at an address divisible by 8. To guarantee this, compilers silently insert padding bytes between struct fields so each one lands on its required boundary, which means a struct's actual memory footprint can be noticeably larger than the sum of its fields' sizes.

Why this matters for tick data

In a market-data tick struct with fields ordered badly — say a 1-byte flag, then an 8-byte double price, then another 1-byte flag — the compiler pads 7 bytes after the first flag so the double aligns on an 8-byte boundary, and likely pads after the second flag too so the whole struct's size is a multiple of its largest field's alignment. A struct packing a bool, a double, and a char might occupy 24 bytes instead of the 10 bytes the raw fields need — over twice as much memory, which means fewer ticks fit per cache line and more cache misses when scanning a large array of them.

Worked example

Reordering the same three fields — double, char, bool — placed largest-to-smallest lets the compiler pack the two 1-byte fields together at the end with minimal padding, shrinking the struct from 24 bytes down to around 16 bytes. In a hot loop scanning millions of ticks, that difference means noticeably more ticks fit in each cache line, directly reducing memory bandwidth and cache misses.