Introduction

Optimizing C code starts with measuring where time or memory is actually being spent. After that, the biggest wins usually come from algorithm choice, memory access patterns, and eliminating unnecessary work. Compiler flags matter, but they do not rescue a slow design or a cache-unfriendly data layout.

Measure Before Changing Code

The first rule of optimization is to profile before guessing. If a function accounts for two percent of runtime, making it twice as fast barely changes the program. If one loop dominates the profile, small improvements there may matter a lot.

A simple build-and-run workflow might start like this:

gcc -O2 -g app.c -o app
./app

Once you know where the hot path is, optimization becomes an engineering task instead of folklore.

Pick Better Algorithms First

No low-level tuning can compensate for the wrong algorithmic complexity. Replacing an O(n^2) approach with an O(n log n) or O(n) one often beats every later micro-optimization combined.

For example, searching a sorted array with binary search is usually a better decision than hand-tuning a linear scan.

1int binary_search(const int *a, int n, int target) {
2    int lo = 0;
3    int hi = n - 1;
4
5    while (lo <= hi) {
6        int mid = lo + (hi - lo) / 2;
7        if (a[mid] == target) return mid;
8        if (a[mid] < target) lo = mid + 1;
9        else hi = mid - 1;
10    }
11
12    return -1;
13}

This is not “micro-optimization.” It is choosing the right work to do.

Improve Memory Access Patterns

C is fast when the CPU sees predictable, contiguous memory access. Cache misses can dominate runtime even when the arithmetic itself is cheap.

For array-heavy code, sequential access is usually better than strided or pointer-chasing access.

for (int i = 0; i < n; ++i) {
    sum += values[i];
}

This is generally more cache-friendly than visiting the same data in a scattered pattern.

Data layout matters too. Sometimes a structure-of-arrays layout performs better than an array-of-structures layout because it improves locality for the specific fields used in the hot loop.

Reduce Dynamic Allocation in Hot Paths

Frequent malloc and free inside tight loops can become expensive. If the program repeatedly allocates short-lived buffers, consider reusing buffers, allocating once up front, or using a custom pool when the lifetime pattern is predictable.

That said, do not replace safe code with hand-rolled memory tricks unless the profiler shows allocation is truly a bottleneck.

Let the Compiler Help

Modern compilers can do a lot if you enable optimization.

Common levels include:

• '-O1'
• '-O2'
• '-O3'

A typical production baseline is:

gcc -O2 app.c -o app

-O3 can sometimes help, but it can also increase code size or hurt performance on certain workloads. Measure rather than assuming the highest flag is automatically best.

Write Clear Loops the Compiler Can Optimize

The compiler is better at optimizing straightforward code than obscure code written in the name of speed. A simple counted loop over arrays is often exactly what vectorization and loop optimizers want to see.

Complicated aliasing assumptions, unpredictable branches, or unnecessary function calls in tight loops may reduce optimization opportunities.

In some cases, adding restrict helps the compiler understand that pointers do not overlap:

1void add_arrays(int n, const float *restrict a,
2                const float *restrict b,
3                float *restrict out) {
4    for (int i = 0; i < n; ++i) {
5        out[i] = a[i] + b[i];
6    }
7}

This should only be used when the non-aliasing guarantee is actually true.

Avoid Premature Branching Tricks

People often reach for branch prediction tricks, loop unrolling, or manual inlining too early. These can matter in rare hot spots, but they are usually later-stage optimizations after the algorithm, layout, and allocation strategy are already correct.

If you optimize in that order, most code gets faster without becoming harder to maintain.

Keep Correctness and Readability in View

Fast wrong code is useless, and overly clever code can become unmaintainable. Good optimization work preserves clear invariants and leaves comments only where the performance reasoning is genuinely non-obvious.

The best optimized C code is often still simple. It just does less unnecessary work and uses memory more intelligently.

Common Pitfalls

• Optimizing before profiling and guessing at bottlenecks.
• Focusing on compiler flags while ignoring algorithmic complexity.
• Writing cache-unfriendly data access patterns.
• Allocating memory repeatedly inside hot loops without evidence it is necessary.
• Using restrict or low-level tricks without actually meeting their correctness requirements.

Summary

• Profile first so you know where optimization matters.
• Algorithm choice usually beats micro-optimization.
• Memory layout and cache-friendly access patterns are major performance factors in C.
• Compiler optimization flags help, but they are not a substitute for good design.
• Apply low-level tricks only after the bigger structural wins are already in place.