Does curly brace scope for comment purpose slow down C++ code?

user_3136752 0
Viewed 1132

Does the curly brace scope for clarifying code boundary increases code execution time? In my opinion, it does. Because exiting curly brace scope in C++ meaning stack unwinding and curly brace scope for comment purpose increases stack unwinding times. But I have no idea whether is expensive or not? Can I ignore the side effect?

You should focus on the code struture other than the code itself of the following code snippet.

#include <iostream>
#include <utility>
#include <vector>
#include <string>

int main()
{
    std::string str = "Hello";
    std::vector<std::string> v;

    {// uses the push_back(const T&) overload, which means 
     // we'll incur the cost of copying str
        v.push_back(str);
        std::cout << "After copy, str is \"" << str << "\"\n";

        //other code involves local variable
     }

    {// uses the rvalue reference push_back(T&&) overload, 
     // which means no strings will be copied; instead, the contents
     // of str will be moved into the vector.  This is less
     // expensive, but also means str might now be empty.
        v.push_back(std::move(str));
        std::cout << "After move, str is \"" << str << "\"\n";

        //other code involves local variable
   }

    std::cout << "The contents of the vector are \"" << v[0]
                                     << "\", \"" << v[1] << "\"\n";
}
c++
4 Answers

Exiting a scope destroys all local variables declared in that scope (youngest first). In your example there are no local variables declared in the scopes, so there should be no overhead. You can confirm this in this case by compiling to assembly language (-s under gcc), with and without the braces and comparing the result.

user_6717030

Modern compilers are smart enough to do nothing when no work is required. In situations when your program does not take advantage of the nested scope created by curly braces, because it does declare any new variables in that scope, the compiler does not insert any additional code to handle the new scope. Moreover, there would be no penalty for introducing local variables with trivial destructors into a nested scope. In general, adding a nested scope may change the timing of work to be done, while the total amount of work would remain the same.

However, adding unnecessary scope may decrease readability of your code. In this case, readability is strictly subjective, so if you like the additional "scope", you can use it penalty-free.

user_3358580

On the contrary: The extra scopes may speed things up. (However, the effect is so slight that you should not bother!)

You see, within a function, the compiler has full control over all the variables the function uses. It will not push some extra variables on the stack where you declare them, and pop them off when they go out of scope. Instead, it will create a stack frame with sufficient space to hold all the local variables that you need. Your compiler is generally smart enough to reuse the space within this stack frame: When one int goes out of scope before another int gets declared, that second int may reuse the slot of the first in the stack frame.

So, when you reduce the scopes of your local variables, you allow the compiler to reuse more slots in the stack frame. This reduces the overall size of your stack, and the distances by which the stack grows/shrinks. This in turn leads to better cache usage, and thus to better performance.

Nevertheless, the impact of this effect is slight, so you should generally ignore it and just write the most readable code you can.

user_24451840

curly brace scope for comment purpose increases stack unwinding times

No, it does not. They affect the lifetime of local variables, but not how many times they are destroyed.

Suppose you have one more std::string object you want to insert into std::vector. Either you place it in the main block or inside extra curly braces block it will be destroyed only once. Only it's lifetime is affected. In the first case it is longer than in the second.

user_721780
Related