Jonathan Boccara's blog

Do Understandable If Statements Run Slower?

Published July 25, 2017 - 6 Comments

Aadam, my esteemed teammate, walked down to me right after reading the last post on Fluent C++, How to Make If Statements More Understandable, with a question. In fact this post made quite a few people think and get back to me with feedback and questions, for which I’m very grateful. If it did just that, then it’s already achieved one of its major goals.

Anyway let’s get to Aadam’s question: “Jonathan, he said, I get the idea of rolling out an if statment for it to match the specifications. But does this have any sort of impact on performance?”

This is a great question, and he wasn’t the only one bringing up this topic.

I had a hunch about the answer, but hunches are worth nothing when it comes to performance, right? So we did the only thing we could do: measure!

To perform all our measurements we’ve used Fred Tingaud’s popular tool: quick-bench.com.

Does the compiler understand understandable if statements?

We’ve selected one particular question for our measurements: we saw in the last post that sometimes, following the specifications leads us to have an if inside an if, as opposed to cramming two conditionals into a logical AND expression:

So does one have a better performance than the other one? And even before this: does the compiler understands that the two snippets are equivalent, and generates the same code for them?

We throw these two pieces of code into quick-bench, that also generates the assembly code for each one. The configuration is clang++ 3.8 launched with -O1 as an optimization flag. We used random numbers for the conditions, in order to make sure they were actually executed at runtime. Here is our quick-bench if you’re curious to have a look.

Here are the two pieces of assembly code that clang generated:

As you can see, except for the memory addresses this is exactly the same generated code. So with -O1, clang figures out that the two pieces of code are equivalent, and therefore they have the same performance.

Now let’s try with -O0 (no optimization):

There is one more line in the code that has two ifs:

which corresponds to a “jump”, the implemenatation of an if statement in assembly code.

Can the CPU live with understandable if statements?

Since the code is different, let’s see how this impacts the time of execution. Let’s give only positive values to a so that the inner if is always executed:

if statement expressive C++ performance

(this image was generated with quick-bench.com)

The version that has the two conditionals on the same line is about 7% faster! So in the case we followed a specifications that led us roll out an if statement like the one in this example, we’ve made the application slower. Blimey!

And now let’s test it with random values for a that can be 0 or 1 with equal probability:

C++ if performance expressive

(this image was generated with quick-bench.com)

This time the second version is about 2% faster, certainly because the execution doesn’t always reach the inner if.

Can I afford understandable if statements??

Let’s analyse the situation calmly.

First of all, if you’re compiling at a sufficient level of optimization, you’re fine. No performance penalty if you choose the if that matches your specifications better. Now the right level of optimization depends on your compiler, but in this experiment it was -O1 for clang. I’ve also generated the code for the latest version of gcc on godbolt (quick-bench doesn’t support gcc as of this writing) for the two ifs and for the if and AND expression. And while the code is also different for -O0, it becomes the same for -O1.

Now if you’re not compiling with optimization, maybe the faster one corresponds to your specifications, in which case you’re also fine. There is not one version of the if that is more understandable in itself, it depends on the flow of the spec.

If your specifications are expressed with the slower if, and this piece of code is not in a critical section for performance, you’re fine again. Indeed, as Scott Meyers explains it in Item 16 of More Effective C++, most of the code isn’t relevant for performance optimizations, and you need to profile your code to figure out which parts are. So 7%, or 2%, or whatever value corresponds to your architecture on that particular line can go completely unnoticed, and it would be a shame to sacrifice its expressiveness for it.

If a certain alignements of the planets causes that particular if to be the bottleneck of your program, then you have to change it. But when you do so, try to do it in a way that would make sense for the specifications. Consult with your domain people if necessary. This way you’re saving the readability of this piece of code in the future.

And if even that isn’t possible, only then can you forgo the readability of this particular line.

But before you get into that extreme situation, you will have saved hundreds of other if statements, that will live on a peaceful life and will thank you for it.

Related articles:

Liked it ? Share this post ! Facebooktwittergoogle_plus    Don't want to miss out ? Follow:   twitterrss

Receive regular updates to make your code more expressive.