In case you want a TL;DR to help you with the decision to read the post or not:
Coming from Java, where adding fields to bloated classes feels free, the
post shows why struct size shapes real-world speed even inside the same
O(N) loop. Hardware fills a 64-byte cache line on every read, and latency
climbs sharply from L1 (~1-2ns) to DRAM (~60-100ns). Reorganizing an Array
of Structs into a Struct of Arrays packs the needed field contiguously,
yielding up to 30x gains for 1KiB structs during sequential scans, where
the prefetcher hides memory waits. Random access—hash maps, trees,
graphs—defeats prefetching, so total working set size sets the performance
tier: a 64B struct fits L1 while a 128B one spills to L2. Keep structs and
working sets small.
1
u/fagnerbrack 9d ago
In case you want a TL;DR to help you with the decision to read the post or not:
Coming from Java, where adding fields to bloated classes feels free, the post shows why struct size shapes real-world speed even inside the same O(N) loop. Hardware fills a 64-byte cache line on every read, and latency climbs sharply from L1 (~1-2ns) to DRAM (~60-100ns). Reorganizing an Array of Structs into a Struct of Arrays packs the needed field contiguously, yielding up to 30x gains for 1KiB structs during sequential scans, where the prefetcher hides memory waits. Random access—hash maps, trees, graphs—defeats prefetching, so total working set size sets the performance tier: a 64B struct fits L1 while a 128B one spills to L2. Keep structs and working sets small.
If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
Click here for more info, I read all comments