The Memory Layout Trick That Turns Rust Structs Into Cache Miss Monsters

A Field Order Problem That Almost Made Me Lose My Mind

The other day I was optimizing a Rust program that processes tons of data. While running benchmarks, I noticed two pieces of code with identical logic had wildly different performance - we’re talking several times slower. I kept checking the algorithm, nothing wrong there. Then a senior dev looked at my code and said: “Your struct field order is wrong.”

I was stunned. Field order? That’s a thing?

He rearranged my struct fields, and performance doubled instantly. That’s when I realized - Rust memory layout is serious business. This is one of those Rust performance optimization tricks that often gets overlooked.

First, Let’s Talk About Memory Alignment

Before we dive into field order, we need to understand memory alignment. Sounds fancy, but it’s actually pretty simple with a real-world example.

Imagine you’re packing a suitcase. You have a few items: a big box (takes 8 slots), a medium box (takes 4 slots), and a small bag (takes 1 slot). The suitcase has rules: the big box must start at a position divisible by 8, the medium box at a position divisible by 4, and the small bag can go anywhere.

If you pack like this:

Position: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
         [S][_][_][_][M][M][M][M][B][B][B][B][B][B][B][B]

Small bag at position 0, takes 1 slot. But the medium box must start at a multiple of 4, so positions 1, 2, 3 are left empty. These empty positions are called padding.

Computers work the same way. When the CPU reads memory, it doesn’t read byte by byte - it reads in “chunks”. If data isn’t aligned to the correct position, the CPU either reads twice or throws an error. So the compiler automatically inserts padding to ensure every field is in the right place.

Rust Memory Layout: How Struct Field Order Affects It

Let’s look at a concrete example:

struct BadLayout {
    a: u8,      // 1 byte
    b: u64,     // 8 bytes
    c: u8,      // 1 byte
    d: u32,     // 4 bytes
}

You might think this struct takes 1+8+1+4=14 bytes, right?

Wrong. It actually takes 24 bytes. Why? Memory alignment:

Position: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18 19 20 21 22 23
         [a][P][P][P][P][P][P][P][b][b][b][b][b][b][b][b][c][P][P][P][d][d][d][d]

• a takes 1 byte, placed at position 0
• b is u64, must be 8-byte aligned, so positions 1-7 are padding
• b takes 8 bytes, placed at positions 8-15
• c takes 1 byte, placed at position 16
• d is u32, must be 4-byte aligned, so positions 17-19 are padding
• d takes 4 bytes, placed at positions 20-23

14 bytes of data forced into 24 bytes. That extra 10 bytes is just air.

Reorder Fields, Save Space Instantly

If we arrange fields from largest to smallest:

struct GoodLayout {
    b: u64,     // 8 bytes
    d: u32,     // 4 bytes
    a: u8,      // 1 byte
    c: u8,      // 1 byte
}

Now the memory layout:

Position: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
         [b][b][b][b][b][b][b][b][d][d][d][d][a][c][P][P]

• b at positions 0-7, perfectly aligned
• d at positions 8-11, also aligned
• a at position 12
• c at position 13
• Last 2 bytes padding to make struct size a multiple of 8

From 24 bytes to 16 bytes, saved 33% memory. Just by changing field order.

But That’s Not Even the Worst Part

Saving memory is nice, but the real killer is CPU cache.

The CPU has a small warehouse called cache, dozens of times faster than main memory. When the CPU reads data, it pulls nearby data into cache too, because programs usually access adjacent data consecutively. This is called a cache line, typically 64 bytes.

Here’s an analogy: you’re shopping at a supermarket with a cart. The cart is your cache, limited capacity. If everything you need is on one shelf, one trip is enough. But if items are scattered across the store, you’re running back and forth. Each extra trip is a cache miss.

Back to our structs. Say you have an array with 1 million structs:

let data: Vec<BadLayout> = vec![...];  // 1 million items, 24 bytes each

// Iterate all elements, only accessing field a
for item in &data {
    process(item.a);
}

Each BadLayout is 24 bytes, a cache line is 64 bytes, so you fit only 2.6 structs per line. But you only need field a, everything else is just along for the ride. The CPU works hard to load data into cache, and you use only a tiny fraction.

With GoodLayout? Each is 16 bytes, so a cache line fits 4. Still some waste, but much better.

Extreme Optimization: Data-Oriented Design

If you really care about performance, consider splitting your struct:

// Traditional object-oriented style
struct Entity {
    position: Vec3,    // 12 bytes
    velocity: Vec3,    // 12 bytes
    health: u32,       // 4 bytes
    name: String,      // 24 bytes
}

let entities: Vec<Entity> = vec![...];

Change to:

// Data-oriented design
struct Entities {
    positions: Vec<Vec3>,
    velocities: Vec<Vec3>,
    healths: Vec<u32>,
    names: Vec<String>,
}

Now when you only need to update all entity positions:

// Traditional: each access skips velocity, health, name
for entity in &mut entities {
    entity.position += entity.velocity;
}

// Data-oriented: sequential access, cache-friendly
for i in 0..entities.positions.len() {
    entities.positions[i] += entities.velocities[i];
}

The data-oriented approach stores positions and velocities contiguously, greatly improving CPU cache utilization. This is the core idea behind the ECS (Entity Component System) architecture used in game engines.

The repr(C) Pitfall

Sometimes you need to interface with C, or need precise control over memory layout, so you use #[repr(C)]:

#[repr(C)]
struct CLayout {
    a: u8,
    b: u64,
    c: u8,
    d: u32,
}

repr(C) tells the compiler: arrange fields according to C language rules, don’t reorder on your own. Field order is entirely up to you, the compiler won’t optimize.

So with repr(C), pay extra attention to field order. Otherwise you think you’re in precise control, but you’re precisely wasting space.

How to Check Your Struct Size

Rust provides std::mem::size_of to check type size:

use std::mem::size_of;

println!("BadLayout: {} bytes", size_of::<BadLayout>());
println!("GoodLayout: {} bytes", size_of::<GoodLayout>());

You can also use std::mem::align_of to check alignment requirements:

use std::mem::align_of;

println!("u8 alignment: {}", align_of::<u8>());    // 1
println!("u32 alignment: {}", align_of::<u32>());  // 4
println!("u64 alignment: {}", align_of::<u64>());  // 8

Real Performance Difference

I ran a simple benchmark, iterating over 1 million structs:

From worst to best, nearly 4x performance difference. Just because of how data is arranged in memory.

Rust Performance Optimization Takeaways

About Rust memory layout and struct field order, remember these points:

1. Struct field order matters: Arrange from largest to smallest to reduce padding
2. Memory alignment is required: CPU demands data at specific positions, compiler auto-inserts padding
3. Reducing cache miss matters more: Optimize Rust memory layout, reduce cache misses, bigger performance gains
4. Data-oriented design: Keep related data together, improve cache utilization
5. Be careful with repr(C): Compiler won’t optimize, field order is all on you

Rust performance optimization isn’t just about algorithms - details like struct field order can make several times difference. Next time you write a struct, don’t randomly order fields. Spend a few seconds thinking about order, might save milliseconds at runtime. When data volume is large, those milliseconds become seconds.

Found this useful? Share it with your Rust buddies. After all, who doesn’t want their code to run faster?