High Performance

By the end of this lesson you'll be able to make C++ run several times faster the right way: measure first, lay your data out so the CPU cache loves it, stop copying things you don't need to, and turn on the compiler optimisations that do the heavy lifting for you.

Learn Python, JavaScript, Java and more with free interactive lessons, real projects and AI-powered help. Beginner-friendly.

Part of the free C++ course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

Think of the CPU as a chef and memory as a giant warehouse. The chef keeps a tiny counter (the cache) right next to the stove. When ingredients sit together on one shelf (a contiguous std::vector ), an assistant grabs a whole tray at once and the chef never waits. When ingredients are scattered all over the warehouse (a node-based std::list ), the assistant runs back and forth for each one — that round trip to RAM is roughly 100× slower than reaching the counter. Most "slow" C++ isn't slow because of clever maths; it's slow because the chef is standing around waiting for memory. Performance work is mostly about keeping the right things on the counter, and about not copying trays you only need to read .

1. Measure First — Never Guess

The golden rule of optimisation is measure, don't guess . Programmers are notoriously bad at predicting where time goes — most of a program's runtime hides in a tiny slice of the code, and the rest is irrelevant. So before you change anything, put a clock around the work and get a real number. A timer is all you need to compare two versions of the same task.

Once you can measure, you can optimise honestly: change one thing, re-run, and keep the change only if the number actually drops. Everything below follows the same pattern — a slow "before" and a fast "after", with a timer proving the difference.

2. Cache Locality — Keep Data Contiguous

The CPU never fetches one byte at a time. It pulls a cache line — usually 64 bytes — into a small, blazing-fast cache. A std::vector stores its elements in one contiguous block , so walking it reads sequential bytes the CPU can prefetch; this is called data-oriented design — laying memory out for how you'll read it. A node-based container like std::list scatters each element somewhere different, so every step risks a cache miss — a trip to RAM that's about 100× slower. The lesson: prefer contiguous containers unless you genuinely need constant-time insertion in the middle.

3. Avoid Unnecessary Copies

A huge amount of accidental slowness comes from copying data you only meant to read . Passing a big std::vector or std::string by value duplicates the whole thing on every call. The fix is to pass large, read-only arguments by const reference ( ) — the function gets a read-only alias to the original and copies nothing. Pass small types ( int , double , a pointer) by value; pass big ones you won't modify by . This is the single highest-value habit in everyday C++ performance.

Your turn. The function below copies the whole vector — and every string inside it — on every call. Change the parameter to a and the loop item to a so nothing is copied. Fill in the two blanks marked ___ :

4. reserve() — Stop Reallocating

When you push_back into a growing std::vector , it occasionally runs out of room, allocates a bigger block, and copies every element it already holds into the new block. Do that as the vector grows from 1 to a million and you've copied a lot of data many times over. If you know roughly how many items you'll add, call vec.reserve(n) once up front: the vector grabs the whole block immediately and never re-copies. It's one line and it's basically free speed.

Now you try. The loop below knows it will add N items, so it should reserve that space first. Fill in the blank with the right call:

5. Inlining, Move & Compiler Flags

Some speed isn't yours to win by hand — it belongs to the compiler. Inlining pastes a small function's body straight into the caller, removing the call overhead; at -O2 the compiler does this for hot functions automatically, so you rarely write inline for speed. Move semantics ( std::move ) hand ownership of a big buffer across instead of copying it. And the biggest lever of all is the optimisation flag : compile a release build with -O2 and the same source can run several times faster than an unoptimised -O0 build.

6. Branch Prediction (Briefly)

Modern CPUs guess which way an if will go before they know the answer, so they can keep working. Guess right (predictable data) and the branch is nearly free; guess wrong (random data) and the CPU throws away ~15–20 cycles of work. You usually don't micro-manage this, but two practical takeaways hold: processing sorted data makes branches predictable, and a branchless expression like avoids the penalty entirely in a hot loop. As always — measure before reaching for either.

Array of Structures (AoS) groups all the fields of one object together: vector<Particle> where each Particle holds x, y, z, mass, type . It reads naturally, but if a loop only needs x , every cache line also drags in y , z , mass and type — mostly wasted.

Structure of Arrays (SoA) flips it: one array per field — vector<float> x, y, z; . Now a loop over all x values reads perfectly sequential memory, so the whole cache line is useful. SoA shines for batch processing (update every particle's position), which is why game engines and simulations lean on it.

Rule of thumb: AoS when you use most fields of one object at a time; SoA when you sweep one field across everything.

No blanks this time — just a brief and an outline. Build a word counter that takes its data by , time it with , and print the count and the microseconds. The point isn't only to make it fast — it's to prove it with a number, exactly like a real performance engineer.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary