Optimizing Struct Memory Layout

1. Why Data Alignment Matters

Before we talk about structures, let's establish a core architectural principle: data alignment. Modern processors (like the ARM and x86 cores you'll encounter) don't access memory one byte at a time. They fetch data in larger, fixed-size chunks, often called "words" (e.g., 4 bytes on a 32-bit system, 8 bytes on a 64-bit system). Access is fastest when the data being fetched fits neatly within one of these chunks and starts at an address that is a multiple of its own size.

When data is unaligned, the CPU might have to perform two separate memory fetches and then stitch the data together, which is significantly slower.

The C standard dictates these alignment requirements:

• char (1 byte): Can be at any address.
• short (2 bytes): Must be at an address divisible by 2.
• int (4 bytes): Must be at an address divisible by 4.
• long, double, pointers (often 8 bytes on 64-bit systems): Must be at an address divisible by 8.

2. Structure Padding: The How and Why

To enforce these alignment rules within a struct, the compiler inserts unused bytes called padding. This ensures that each member begins on its required memory boundary. This often makes the total size of the struct larger than the sum of its members.

The Rules of Structure Padding

Based on the video and standard compiler behavior, we can distill the process into two key rules:

1. Internal Padding: Each member of the struct must be placed at an offset from the start of the struct that is a multiple of its own alignment requirement. The compiler will insert padding bytes before a member to satisfy this.
2. Trailing Padding: The total size of the entire struct must be a multiple of the alignment of its widest member. This ensures that in an array of these structs, every struct instance will start on a properly aligned boundary.

Manual Calculation Exercise

Let's apply these rules to a typical interview-style problem. Given a 64-bit system (where pointers are 8 bytes), calculate the size of the following struct:

struct device_register {
    char    status;     // 1 byte
    long    device_id;  // 8 bytes
    int     config;     // 4 bytes
    short   checksum;   // 2 bytes
};

Let's walk through it:

1. Struct Alignment: The widest member is long device_id (8 bytes). Therefore, the entire struct device_register must have an 8-byte alignment, and its total size must be a multiple of 8.

2. Member Layout:

   • char status: Size 1. Placed at offset 0.
   • long device_id: Size 8. Needs an 8-byte aligned offset. The next available multiple of 8 is offset 8. The compiler inserts 7 padding bytes after status. device_id is placed at offset 8.
   • int config: Size 4. Placed at offset 16 (8 + 8). Its own alignment (4) is satisfied.
   • short checksum: Size 2. Placed at offset 20 (16 + 4). Its own alignment (2) is satisfied.

3. Trailing Padding:

   • The last member, checksum, ends at offset 22 (20 + 2).
   • The total size must be a multiple of the struct's alignment (8).
   • The next multiple of 8 after 22 is 24.
   • The compiler adds 2 bytes of trailing padding.

Result: The sizeof(struct device_register) is 24 bytes. (1 + 7 + 8 + 4 + 2 + 2)

3. Structure Reordering: Minimizing Memory Footprint

As you saw, the order of members dramatically impacts the amount of padding. We can exploit this to save memory, which is critical in constrained embedded systems or when dealing with large datasets.

The general rule for optimization is simple: Declare structure members in order of decreasing alignment requirement.

Reordering Exercise

Let's reorder our device_register struct and see the effect.

// Original struct (24 bytes)
struct device_register {
    char    status;
    long    device_id;
    int     config;
    short   checksum;
};

// Reordered struct
struct device_register_optimized {
    long    device_id;  // 8 bytes
    int     config;     // 4 bytes
    short   checksum;   // 2 bytes
    char    status;     // 1 byte
};

Let's recalculate:

1. Struct Alignment: Still determined by long device_id (8 bytes).
2. Member Layout:
   • long device_id: Size 8. Placed at offset 0.
   • int config: Size 4. Placed at offset 8. Alignment is satisfied.
   • short checksum: Size 2. Placed at offset 12. Alignment is satisfied.
   • char status: Size 1. Placed at offset 14. Alignment is satisfied.
   • No internal padding is needed!
3. Trailing Padding:
   • The last member, status, ends at offset 15.
   • The total size must be a multiple of 8. The next multiple is 16.
   • The compiler adds 1 byte of trailing padding.

Result: The sizeof(struct device_register_optimized) is 16 bytes. By simply reordering the members, we achieved a 33% reduction in memory usage.

4. Advanced Case: Nested Structures

A common point of confusion, and thus a great interview question, is how padding works with nested structures. The key is that the alignment rule propagates upwards from the most-aligned member, wherever it may be.

The takeaway is that the alignment of an outer struct is determined by the alignment of the widest scalar member anywhere inside it, including within nested structs.

Conclusion

Mastering data alignment and structure padding is non-negotiable for a senior embedded role. It demonstrates an understanding that goes beyond just writing code to understanding how that code interacts with the hardware.

Key Takeaways:

• Alignment is for Performance: Compilers add padding to ensure that each data member is naturally aligned, allowing the CPU to access it with the fewest memory operations.
• Calculate with Two Rules:
  1. Add internal padding so each member starts at an offset that is a multiple of its own alignment.
  2. Add trailing padding so the struct's total size is a multiple of its widest member's alignment.
• Optimize by Reordering: You can significantly reduce a struct's memory footprint by ordering members from largest to smallest alignment requirement.
• Nested Structures: The alignment of a nested struct is determined by the widest scalar member within it, and this influences the layout of the parent struct.

Preview of the Next Lesson:

While reordering is a powerful technique for saving memory, sometimes you need to do the opposite: force a specific, non-optimal memory layout. This is common when your struct needs to exactly match a hardware register block or a network protocol packet definition. In our next lesson, we will learn how to do this by exploring compiler-specific directives: Apply #pragma pack and __attribute__((packed)) to control data alignment and explain the performance trade-offs.