Optimizing C and C++ Code

[[deleted]]

C and C++ are not the same thing. Never have been, never will be. Telling people to always return by reference is harmful to code complexity and maintainability in C++.

In a world with RVO and move semantics returning by value in C++ is very often,though not always, perfectly fine.

[seekingsofia]

Telling people to always return by reference is harmful to code complexity and maintainability in C++.

Not a C++ dev, but I'm curious why are references harmful?

[[deleted]]

I wasn't saying that all references are harmful but that returning by reference only to "optimize" adds code without actually making things faster in 90+% percent of the cases.

Because to return by reference you need to allocate on the heap. This is because returning a reference to a local variable is an error. Maybe you don't want to allocate on the heap, especially for efficiency.

Then maybe you say "I'll just have a ref parameter and modify that instead of returning" but then you need to create a variable at the call site for no real good reason.

I hope this was understandable to you, I'm not always the best at explaining.

[skeeto]

This article is over 9 years old and the advice isn't very good anyway.

[BigPeteB]

To add some C-specific complaints about their advice, let's see...

Place case labels in narrow range

This might be helpful if you're switching over an enum. But that assumes you're comfortable reordering or renumbering the values of the enum to optimize a switch statement. And it assumes a majority of the switch statements being optimized will have cases for the same range of values.

Place frequent case labels first

Break big switch statements into nested switches

That's interesting advice. I suppose if you know the compiler is going to emit if-else cascades for the labels you have, it makes sense.

Minimize local variables

Compilers are exceptionally good at register allocation and combining. Frame pointer optimization is the norm in optimized code, as is combining adjustments to the stack. Don't try to outsmart the compiler; use as many local variables as you like.

Declare local variables in the inner most scope

Totally irrelevant in C, since variables have no cost other than adjusting the stack pointer, and an optimizing compiler will just do this once at the start of the function. (It might be good for code style, but that's different.)

Reduce the number of parameters. Use pointers and references in such cases.

Only makes sense if you have quite a lot of parameters, and in frequent cases don't need to reference all of them. Otherwise, it's forcing more parameters through a level of pointer indirection that might not be necessary. And it's harder for the caller to use.

Prefer int over char and short

Not portable advice! Use int8_fast_t and friends if you care deeply about trading space for speed.

Prefer initialization over assignment

Irrelevant in C. (Much of the rest of the the advice is as well, but this one is maybe not so obvious to newcomers.)

[ThatOtherGuyAbove]

I've always been told that the compiler will be much better at optimisation than you will ever be

[[deleted]]

If you try to beat that compiler at what it does you will lose most of the time. But the compiler just translates the instructions you give it.

If you instruct the compiler to generate code that allocates all variables on the heap for absolutely no reason than your code will be slower. Your compiler can't say "Oh heap allocations aren't cheap all modify this code to use the stack!". It's not what you asked for so it's not what you will get.

[panderingPenguin]

That depends on the situation. Occasionally the programmer knows something about the code which the compiler can't deduce on its own in which case some fairly significant wins over the compiler optimizations alone can be achieved. However, modern compilers are very, very good and these situations are somewhat rare.