I want to talk about making Rust code fast. Rust is already known for being quick, but that speed isn’t automatic. It comes from understanding what your code is actually doing and making thoughtful changes. To do that, you need to measure first. Guessing about performance is a great way to waste time. You might spend hours optimizing a function that only runs once at startup. Instead, you should find the parts that matter—the bottlenecks—and focus your efforts there.

Let’s look at some practical ways to do this. I think of it as a process: first, learn to measure accurately. Then, use those measurements to guide your changes. Finally, verify that your changes actually made things better. It’s a cycle of measure, change, and measure again.

A great starting point is Cargo’s built-in benchmark tool. It’s simple. You write a special function, and Cargo runs it many times, telling you how long it takes. This is perfect for getting a quick sense of whether a new approach is faster than an old one. You do need to use a nightly version of the Rust compiler for this, but it’s a good way to get your feet wet with benchmarking.

Here’s what that looks like. You mark your benchmark with #[bench] and use a Bencher. The black_box function is important. It stops the compiler from being too clever and optimizing away the very code you’re trying to test.

#![feature(test)]
extern crate test;

pub fn double_value(input: u64) -> u64 {
    input.wrapping_mul(2)
}

#[cfg(test)]
mod tests {
    use super::*;
    use test::{black_box, Bencher};

    #[bench]
    fn bench_doubling(b: &mut Bencher) {
        b.iter(|| {
            // black_box prevents the compiler from seeing the input as a constant
            let num = black_box(150_u64);
            let result = double_value(num);
            // We also black_box the result so the entire computation isn't removed.
            black_box(result);
        });
    }
}

You’d run this with cargo bench. It will output the average time per iteration. This gives you a baseline number. Later, if you tweak the double_value function, you can run the benchmark again to see if the time goes down.

For more serious, everyday work, I rely on Criterion.rs. It works on the stable Rust compiler and gives you much more reliable information. Criterion doesn’t just give you a single time; it runs many iterations, performs statistical analysis, and can even tell you if a change is a real improvement or just random noise. It also creates helpful charts and stores historical data, so you can track performance over time.

Setting up Criterion is straightforward. You add it to your Cargo.toml and create a small benchmark file.

use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn process_string(input: &str) -> String {
    // A simple, somewhat inefficient operation for demonstration
    input.chars().rev().collect::<String>().to_uppercase()
}

fn bench_string_processing(c: &mut Criterion) {
    let test_data = "The quick brown fox jumps over the lazy dog.";
    
    c.bench_function("reverse and uppercase", |b| {
        b.iter(|| process_string(black_box(test_data)))
    });
}

// This sets up the benchmark group and main function.
criterion_group!(string_benches, bench_string_processing);
criterion_main!(string_benches);

After running cargo bench, Criterion will show you detailed output, including mean time, outliers, and a comparison to a previous run if you have one. This statistical rigor is what turns “I think it’s faster” into “I am 95% confident it is faster.”

Benchmarks are excellent for isolated functions, but sometimes the problem is in the interaction between parts of your program. That’s where a profiler comes in. A profiler runs your whole application and shows you a map of where time is being spent. It points directly at the functions that are consuming the most CPU cycles.

On Linux, perf is a powerful tool. After building your program in release mode, you can record its execution. The report shows a ranked list of functions. Seeing that 70% of your program’s runtime is in one specific parsing function is a powerful motivator for optimization.

# Build the optimized binary
cargo build --release

# Record performance data while running the program
perf record --call-graph dwarf ./target/release/my_data_processor input.txt

# Generate a report to view the hotspots
perf report

The first time I used perf on a web server I was building, I was shocked. A huge portion of time was being spent in a function that formatted log messages, even when logging was turned off! The profiler showed me the problem immediately, and I fixed it by using a conditional check. You can’t argue with that kind of data.

Once you’ve identified a hot function, you might want to know exactly what the computer is doing. You can ask the Rust compiler to show you the assembly code it generates. This is a more advanced technique, but it demystifies the cost of your code. You can see if a loop was efficiently vectorized or if there are unexpected function calls.

The easiest way is using the Compiler Explorer website. You paste your Rust code in one pane and see the resulting assembly in another. For local inspection, you can use a Cargo command.

// A function we suspect is critical
pub fn sum_squares(slice: &[i32]) -> i32 {
    slice.iter().map(|&x| x * x).sum()
}

To see the assembly, you could run:

cargo rustc --release -- --emit asm

The output file will be in target/release/deps/. Looking at it, you might search for instructions like mul and add inside a loop. If the loop is tight and clean, that’s good. If you see calls to a function like panic_bounds_check, you might realize an indexing operation is causing checks you could avoid by using iterators differently.

A common question is about inlining. Should you add #[inline] to your functions? The compiler has good rules for this. It will usually inline small functions. But sometimes, especially in a hot loop across crate boundaries, the compiler might decide not to. If profiling shows a lot of time spent on the call instruction itself for a tiny function, you can suggest inlining.

// A small, frequently called function in a math library
#[inline]
pub fn clamp(value: f32, min: f32, max: f32) -> f32 {
    if value < min {
        min
    } else if value > max {
        max
    } else {
        value
    }
}

Be careful, though. Telling the compiler to inline a large function everywhere can make your binary huge and slow things down by hurting cache performance. Use #[inline] as a hint, not a command, and always check the effect with a benchmark.

Often, the biggest speed gains don’t come from fiddling with instructions but from organizing your data better. Computers are fast at computation but relatively slow at fetching data from memory. If your data is laid out so the processor can predict what it needs next, everything gets faster.

The classic advice is to prefer arrays and vectors when you process data in order. The processor will prefetch the next elements before you even ask for them. A more advanced idea is the structure-of-arrays transformation. Imagine you have a bunch of game entities.

// The common way: Array of Structs (AoS)
struct Entity {
    health: i32,
    position_x: f32,
    position_y: f32,
    velocity_x: f32,
    velocity_y: f32,
}
let mut entities: Vec<Entity> = Vec::new();

// Update all positions
for entity in entities.iter_mut() {
    entity.position_x += entity.velocity_x;
    entity.position_y += entity.velocity_y;
}

This works fine. But what if you only need to update positions for a physics step? The health field is being loaded into the cache uselessly. A structure-of-arrays layout can be more efficient for bulk operations.

// Structure of Arrays (SoA) - better for batch operations on specific fields
struct World {
    healths: Vec<i32>,
    positions_x: Vec<f32>,
    positions_y: Vec<f32>,
    velocities_x: Vec<f32>,
    velocities_y: Vec<f32>,
}

impl World {
    fn update_positions(&mut self) {
        for i in 0..self.positions_x.len() {
            self.positions_x[i] += self.velocities_x[i];
            self.positions_y[i] += self.velocities_y[i];
        }
    }
}

Now, when update_positions runs, it streams through contiguous arrays of only the data it needs. This can lead to much better cache usage and significant speedups for numerical workloads. The trade-off is that the code becomes less intuitive.

Memory allocation is another major source of slowdown. Asking the operating system for new memory is expensive. In a tight loop, creating a new Vec or String on every iteration can dominate your runtime. The solution is to allocate once and reuse.

For collections, tell them how much capacity they’ll need upfront if you know. For temporary buffers, create them outside the loop and clear them for reuse.

fn join_all_strings_with_separator(strings: &[&str], separator: &str) -> String {
    // Estimate capacity to avoid multiple re-allocations as the String grows.
    let total_length: usize = strings.iter().map(|s| s.len()).sum();
    let separator_count = strings.len().saturating_sub(1);
    let estimated_len = total_length + (separator.len() * separator_count);
    
    let mut result = String::with_capacity(estimated_len);
    
    for (i, s) in strings.iter().enumerate() {
        if i > 0 {
            result.push_str(separator);
        }
        result.push_str(s);
    }
    
    // The 'result' String likely never needed to reallocate its memory.
    result
}

// Example of reusing a buffer across operations
let mut scratch_space = Vec::with_capacity(1024); // Allocate once

for data_chunk in large_data_set {
    scratch_space.clear(); // Reset length to 0, keeps the allocated memory
    // ... process data_chunk into scratch_space ...
    process_results(&scratch_space);
}

I once fixed a 30% performance issue in a parser just by changing let mut buffer = Vec::new(); inside a loop to let mut buffer = Vec::with_capacity(128); and moving it outside the loop. The program was spending more time allocating and freeing tiny chunks of memory than it was doing actual parsing work.

Finally, make sure you’re telling the compiler to do its best work. Always use --release for final builds. You can also give hints about your target CPU. If you’re building software specifically for the machine it will run on, you can enable every advanced instruction your CPU supports.

You can add this to your .cargo/config.toml file:

[build]
rustflags = ["-C", "target-cpu=native"]

This allows the compiler to use SSE, AVX, or other specialized instructions for things like floating-point math or byte operations. For the bravest, Rust offers access to Single Instruction, Multiple Data (SIMD) intrinsics, which let you operate on multiple pieces of data at once. Libraries like packed_simd (note: as of my knowledge cutoff, this crate is in flux, with efforts to integrate SIMD into std) provide a safer interface for this.

// This is a conceptual example. Actual SIMD usage requires specific crates or nightly features.
// It shows the idea: process 4 floats at once instead of 1.
use std::simd::f32x4; // Note: This is an experimental API as of Rust 1.58

fn simd_sum(values: &[f32]) -> f32 {
    let chunks = values.chunks_exact(4);
    let mut sum = f32x4::splat(0.0); // Create a vector of four 0.0s
    
    for chunk in chunks {
        let vector = f32x4::from_slice(chunk);
        sum += vector;
    }
    
    // Horizontal add: sum the four lanes of the vector
    let scalar_sum = sum.as_array().iter().sum();
    
    // Handle any remaining elements (less than 4)
    let remainder = chunks.remainder();
    scalar_sum + remainder.iter().sum::<f32>()
}

This is an advanced optimization, but for data-processing tasks, the speedups can be dramatic—four times faster or more. Always benchmark before and after, as SIMD has its own complexities.

The main idea I want to leave you with is this: performance work is a dialogue. You ask your code a question by measuring it. You make a change based on what you learn. Then you measure again to see if you got the right answer. Start with the big picture from a profiler, use benchmarks to confirm specific improvements, and peer at assembly when you need to understand the fine details. By combining these techniques, you move from hoping your Rust code is fast to knowing exactly how fast it is—and how to make it faster.