Balancing Simplicity and Performance in C++ Development

Arne Mertz, a C++ enthusiast with extensive development experience, explains the relationship between simplicity and performance, urging developers not to sacrifice readability for speed unless absolutely necessary and to use tools to resolve performance issues.

Translation:

C++ is known for allowing very high‑performance code, but how should we gauge the appropriate level of performance work in practice?

Performance ≠ Efficiency

First, we must distinguish performance (how fast something can run) from efficiency (how much time it takes to complete a task).

How fast we can do something (performance);

How long it takes to finish (efficiency).

These concepts seem similar but are not. For example, traveling from point A to B: efficiency means taking the shortest path, while performance means “running instead of walking.” Even if you reach the destination at Bolt’s speed (high performance), you are not efficient because you didn’t choose the shortest route.

In programs, loops often consume a lot of time. Here, performance means “shorter per‑iteration time,” while efficiency means “reducing loop depth.”

Performance is not everything

This is an obvious truth that beginners often overlook. Many forum questions focus on code‑level performance optimizations.

It is said that 80% of execution time is spent in roughly 20% of the code (or 90%/10%). Thus, the critical computational parts usually reside in a small fraction of the code. Spending effort optimizing every line yields diminishing returns.

Do we really not know how to write high‑performance code?

In fact, the main factor determining runtime is the number of instructions, which is largely controlled by the compiler and its optimizer, not directly by us.

Optimizers are numerous and complex; unless you are an expert, it is hard to know exactly what transformations they apply (e.g., eliminating temporaries, inlining functions, removing redundant instructions).

Because of these uncertainties, writing absolutely optimal code is difficult. If performance matters, use profiling and analysis tools to guide improvements.

Nevertheless, stay pragmatic: when two or more readable implementations exist, prefer the faster one. For instance, use ++iter instead of iter++ when the result is not stored.

Performance and simplicity are not always contradictory

Another key factor affecting runtime is the layout and structure of data in memory. See Chandler Carruth’s article “Efficiency with Algorithms, Performance with Data Structures” for details.

If data layout is poor, fetching data can become costly and cause instruction redundancy.

For more on simplicity versus performance, refer to the article “Using the libraries you have, and using them right.”

Summary

Prefer writing readable and simple code by default. If a genuine performance bottleneck is identified, there are many ways to address it without resorting to overly complex solutions. Avoid sacrificing simplicity for speed unless absolutely necessary, and leverage tools to solve performance problems.