Memory efficiency in Rust isn’t just a feature—it’s a fundamental part of the language’s design philosophy. Over years of working with systems programming, I’ve found that Rust provides tools that feel almost like having a direct conversation with the hardware. You can express exactly how data should live in memory, and the compiler becomes your meticulous partner in enforcing those decisions.

Let me share some techniques that have transformed how I approach data structure design.

When working with enums, Rust’s compiler performs clever optimizations automatically. The language selects the smallest integer type capable of representing all variants, but you can take explicit control when needed. I often use #[repr(u8)] or similar annotations to ensure my enums use minimal space.

Consider this user status example:

#[repr(u8)]
enum Status {
    Active,
    Inactive,
    Suspended,
}

struct User {
    id: u64,
    status: Status, // Now uses only 1 byte instead of 8
}

This simple annotation saves seven bytes per user. When dealing with millions of users, those savings become substantial.

Arena allocation has become one of my favorite patterns for managing groups of related objects. Instead of allocating each object separately, you create a memory arena that holds everything together. This approach reduces allocation overhead dramatically and improves cache performance.

Here’s how I typically implement arena allocation:

use bumpalo::Bump;

struct Graph<'a> {
    nodes: Vec<Node<'a>>,
    arena: &'a Bump,
}

impl<'a> Graph<'a> {
    fn new(arena: &'a Bump) -> Self {
        Self {
            nodes: Vec::new(),
            arena,
        }
    }
    
    fn add_node(&mut self, data: &str) -> &Node<'a> {
        let node_data = self.arena.alloc_str(data);
        let edges = Vec::new_in(self.arena);
        
        let node = self.arena.alloc(Node {
            data: node_data,
            edges,
        });
        
        self.nodes.push(node);
        node
    }
}

The lifetime parameter 'a ensures all nodes share the arena’s lifetime. When the arena gets dropped, everything cleans up together. This pattern works exceptionally well for parse trees, graph structures, or any scenario where objects have connected lifetimes.

For storing large collections of boolean values or small integers, bit-level packing offers remarkable density. I’ve used this technique in database systems and network protocols where every bit matters.

Here’s a simple bit set implementation:

struct BitSet {
    storage: Vec<u64>,
}

impl BitSet {
    fn with_capacity(capacity: usize) -> Self {
        let words_needed = (capacity + 63) / 64;
        Self {
            storage: vec![0; words_needed],
        }
    }
    
    fn set(&mut self, index: usize, value: bool) {
        let word_index = index / 64;
        let bit_offset = index % 64;
        
        if value {
            self.storage[word_index] |= 1 << bit_offset;
        } else {
            self.storage[word_index] &= !(1 << bit_offset);
        }
    }
    
    fn get(&self, index: usize) -> bool {
        let word_index = index / 64;
        let bit_offset = index % 64;
        
        self.storage.get(word_index)
            .map(|word| (word >> bit_offset) & 1 == 1)
            .unwrap_or(false)
    }
}

This implementation stores 64 boolean values in the space of a single u64. The memory savings are particularly valuable when working with large datasets.

Rust’s type system allows us to include compile-time information without runtime cost. Phantom types and zero-sized types serve as markers that carry meaning for the compiler but vanish during execution.

I often use them for type safety in generic contexts:

struct Id<T> {
    value: u64,
    _marker: std::marker::PhantomData<T>,
}

impl<T> Id<T> {
    fn new(value: u64) -> Self {
        Self {
            value,
            _marker: std::marker::PhantomData,
        }
    }
}

struct User;
struct Product;

fn process_user(id: Id<User>) {
    // Can only accept user IDs
    println!("Processing user ID: {}", id.value);
}

This technique prevents mixing different types of identifiers while adding no memory overhead. The PhantomData field doesn’t occupy any space in memory—it only exists at compile time.

Custom allocators let you match memory management patterns to specific use cases. When standard allocation becomes too general, creating specialized allocators can yield significant performance benefits.

Here’s a simple pool allocator I’ve used for fixed-size objects:

struct PoolAllocator<T> {
    blocks: Vec<Box<[T; 1024]>>,
    free_list: Vec<usize>,
}

impl<T> PoolAllocator<T> {
    fn new() -> Self {
        Self {
            blocks: Vec::new(),
            free_list: Vec::new(),
        }
    }
    
    fn allocate(&mut self) -> Option<&mut T> {
        if self.free_list.is_empty() {
            let new_block = Box::new(std::array::from_fn(|_| unsafe {
                std::mem::MaybeUninit::zeroed().assume_init()
            }));
            self.blocks.push(new_block);
            
            for i in 0..1024 {
                self.free_list.push((self.blocks.len() - 1) * 1024 + i);
            }
        }
        
        self.free_list.pop().map(|index| {
            let block_index = index / 1024;
            let item_index = index % 1024;
            &mut self.blocks[block_index][item_index]
        })
    }
}

This allocator pre-allocates blocks of memory and manages individual items within those blocks. It eliminates fragmentation and reduces allocation overhead for scenarios where you need many small objects of the same size.

Storing data contiguously often outperforms pointer-based structures. I frequently use slice-based storage when working with collections that benefit from memory locality.

This string table implementation demonstrates the approach:

struct StringTable {
    storage: String,
    offsets: Vec<(usize, usize)>,
}

impl StringTable {
    fn new() -> Self {
        Self {
            storage: String::new(),
            offsets: Vec::new(),
        }
    }
    
    fn add(&mut self, s: &str) -> usize {
        let start = self.storage.len();
        self.storage.push_str(s);
        let end = self.storage.len();
        
        self.offsets.push((start, end));
        self.offsets.len() - 1
    }
    
    fn get(&self, index: usize) -> &str {
        let (start, end) = self.offsets[index];
        &self.storage[start..end]
    }
}

All strings live in a single contiguous buffer. The offsets vector stores start and end positions. This structure reduces memory fragmentation and improves cache performance when accessing multiple strings sequentially.

Variable-length encoding compresses data by using fewer bytes for smaller values. I’ve implemented this in serialization formats and database storage engines.

Here’s a variable integer encoding function:

fn encode_varint(value: u64, buffer: &mut Vec<u8>) {
    let mut val = value;
    
    while val >= 0x80 {
        buffer.push((val as u8) | 0x80);
        val >>= 7;
    }
    
    buffer.push(val as u8);
}

fn decode_varint(buffer: &[u8]) -> Option<(u64, usize)> {
    let mut result: u64 = 0;
    let mut shift = 0;
    let mut bytes_used = 0;
    
    for &byte in buffer {
        bytes_used += 1;
        result |= ((byte & 0x7F) as u64) << shift;
        
        if byte & 0x80 == 0 {
            return Some((result, bytes_used));
        }
        
        shift += 7;
        if shift >= 64 {
            return None; // Overflow
        }
    }
    
    None // Incomplete data
}

Small values use one byte, while larger values use progressively more bytes. This encoding works exceptionally well for data where most values are small, but occasional large values need accommodation.

Eliminating data copying represents one of Rust’s most powerful capabilities. When working with large datasets or network protocols, I often use zero-copy techniques to avoid unnecessary memory operations.

This unsafe function demonstrates the concept:

unsafe fn view_bytes_as_type<'a, T>(bytes: &'a [u8]) -> Result<&'a T, &'static str> {
    if bytes.len() < std::mem::size_of::<T>() {
        return Err("Insufficient bytes");
    }
    
    let alignment = std::mem::align_of::<T>();
    let ptr = bytes.as_ptr();
    
    if (ptr as usize) % alignment != 0 {
        return Err("Unaligned access");
    }
    
    Ok(&*(ptr as *const T))
}

Safety remains crucial when using these techniques. I always validate alignment and size requirements before proceeding. For production code, I prefer using established libraries like zerocopy that provide safe abstractions.

Each technique offers different trade-offs. Compact enums work well for type representations. Arena allocation excels for connected data. Bit packing suits flag collections. Zero-sized types enable compile-time safety. Custom allocators match specific patterns. Slice storage improves locality. Variable encoding compresses data. Zero-copy methods reduce overhead.

The true power emerges when combining these approaches. I might use arena allocation for a graph structure while employing bit packing for node properties and variable encoding for storage serialization. Rust’s ownership system ensures these optimizations don’t compromise safety.

Memory efficiency requires thoughtful design decisions. I consider access patterns, lifetime relationships, and typical data sizes. Sometimes the simplest solution works best. Other situations demand creative combinations of these techniques.

Rust provides the tools, but experience guides their application. Through practice and experimentation, these patterns become natural parts of the systems programmer’s toolkit. The result is software that uses memory efficiently while maintaining clarity and safety.