Variable scoping effect at runtime

General norm

As a general rule, it is advisable to reduce the scope of variables as much as possible. This statement is supported by the fact that sharing a variable for different uses often makes the code more difficult to read and maintain.

• The compiler will not warn us if we forget to initialize it between the first use and the second, no matter how restrictive the compilation is.
• It will be difficult to parallelize the algorithm.
• The variable name will generally be less descriptive, making the code more difficult to read.

If, on top of that, we declare the variables as global, the matter becomes even more complicated and it's not worth mentioning if, apart from global variables, we start using threads.

Scope vs performance (native types)

A detail that is usually alleged in defense of extending the life of variables is the issue of performance. It is defended that declaring the variable only once prevents it from having to be created and destroyed, thus improving the performance of the application.

This is not technically correct, at least not with modern compilers. To demonstrate this we will use an example like the following:

extern int PideNumero();
extern void ExternFunc();

void func1()
{
  int num = PideNumero();
  int i;

  for( i=0; i<num; i++ )
  {
    ExternFunc();
  }

  for( i=0; i<num; i++ )
  {
    ExternFunc();
  }
}

The functions are marked as externbecause I don't care about their content or that the compiler converts them to inline. I do it like this to make the examples simpler.

If we compile this code in release mode and analyze the resulting assembler (for this you can use this tool ) we get a sequence like the following (example with gcc 6.2 compiled with -O3):

func1():
    push    rbp
    push    rbx
    sub     rsp, 8
    call    PideNumero()
    test    eax, eax
    jle     .L1
    mov     ebp, eax
    xor     ebx, ebx
.L6:
    add     ebx, 1
    call    ExternFunc()
    cmp     ebp, ebx
    jne     .L6
    xor     ebp, ebp
.L5:
    add     ebp, 1
    call    ExternFunc()
    cmp     ebx, ebp
    jne     .L5
.L1:
    add     rsp, 8
    pop     rbx
    pop     rbp
    ret

The code is basically structured as follows:

• .L6: Represents the start of the first loop
• .L5: Represents the start of the second loop
• .L1: An optimization on account of the compiler, if numit is worth 0 it skips directly to the end of the function.

As you can see, the compiler is making use of the registers ebxfor the first loop and ebpfor the second. Instead of creating the variable on the stack, it is making use of the processor's internal registers. The cost of creating the variable is, in this case, 0.

Now we go with a second version. In this case, the scope of the variable will be reduced to the scope of the loop itself:

extern int PideNumero();
extern void ExternFunc();

int func1()
{
  int num = PideNumero();

  for( int i=0; i<num; i++ )
  {
    ExternFunc();
  }

  for( int j=0; j<num; j++ )
  {
    ExternFunc();
  }
}

The resulting assembler is the following:

func1():
    push    rbp
    push    rbx
    sub     rsp, 8
    call    PideNumero()
    test    eax, eax
    jle     .L1
    mov     ebp, eax
    xor     ebx, ebx
.L6: 
    add     ebx, 1
    call    ExternFunc()
    cmp     ebp, ebx
    jne     .L6
    xor     ebp, ebp
.L5:
    add     ebp, 1
    call    ExternFunc()
    cmp     ebx, ebp
    jne     .L5
.L1:
    add     rsp, 8
    pop     rbx
    pop     rbp
    ret

If both sequences are compared, we see that they are exactly the same. The exact same registers are used ebxand ebpfor each loop then creating the variables is a free process .

What happens then if we have nested loops?

Given the following code:

extern int PideNumero();
extern void ExternFunc();

void func1()
{
  int num = PideNumero();

  for( int i=0; i<num; i++ )
  {
    for( int j=0; j<num; j++ )
      ExternFunc();
  }
}

The resulting assembler is the following:

func1():
    push    r12
    push    rbp
    push    rbx
    call    PideNumero()
    test    eax, eax
    jle     .L1
    mov     ebp, eax
    xor     r12d, r12d
.L7:
    xor     ebx, ebx
.L3:
    add     ebx, 1
    call    ExternFunc()
    cmp     ebp, ebx
    jne     .L3
    add     r12d, 1
    cmp     ebp, r12d
    jne     .L7
.L1:
    pop     rbx
    pop     rbp
    pop     r12
    ret

We see that the processor registers are used again. In this case you are using ebxand r12d, but they are still processor registers, so the cost of creating the variable jon each iteration of the first loop is 0.

It is then clear that when using native types there is no difference between sharing variables or not, so the supposed benefits of extending the scope of variables is, in this case, a false myth.

Scope vs performance (structures and classes)

For this example we are going to create a wrapper that encapsulates an integer and implements the minimum functions necessary for the code to compile:

struct IntWrapper
{
  int num;

  IntWrapper(int valor)
    : num(valor)
  { }

  IntWrapper& operator++(int)
  {
    num++;
    return *this;
  }

  bool operator<(IntWrapper const& otro)
  {
    return num < otro.num;
  }
};

extern IntWrapper PideNumero();
extern void ExternFunc();

void func1()
{
  IntWrapper num = PideNumero();

  for( IntWrapper i=0; i<num; i++ )
  {
    for( IntWrapper j=0; j<num; j++ )
      ExternFunc();
  }
}

what happens in this case? Let's see:

func1():
    push    r12
    push    rbp
    push    rbx
    call    PideNumero()
    test    eax, eax
    jle     .L1
    mov     ebp, eax
    xor     r12d, r12d
.L6:
    xor     ebx, ebx
.L3:
    add     ebx, 1
    call    ExternFunc()
    cmp     ebp, ebx
    jne     .L3
    add     r12d, 1
    cmp     r12d, ebp
    jne     .L6
.L1:
    pop     rbx
    pop     rbp
    pop     r12
    ret

Surprisingly the code is practically the same. The compiler is able to extract the integer from the wrapper and generate code just as efficient as in the previous cases.

Now we only need to check what happens in the case of more complex classes. An example using std::stringoutside of the loop:

#include <string>

extern int PideNumero();
extern void ExternFunc(std::string const&);

void func1()
{
  int num = PideNumero();

  std::string cad = "ABCD";

  for( int i=0; i<num; i++ )
  {
    ExternFunc(cad);
  }
}

And its output:

func1():
    push    rbp
    push    rbx
    sub     rsp, 40
    call    PideNumero()
    mov     ebp, eax
    lea     rax, [rsp+16]
    mov     DWORD PTR [rsp+16], 1145258561
    test    ebp, ebp
    mov     QWORD PTR [rsp+8], 4
    mov     BYTE PTR [rsp+20], 0
    mov     QWORD PTR [rsp], rax
    jle     .L1
    xor     ebx, ebx
.L9:
    mov     rdi, rsp
    call    ExternFunc(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    add     ebx, 1
    cmp     ebp, ebx
    jne     .L9
    mov     rdi, QWORD PTR [rsp]
    lea     rax, [rsp+16]
    cmp     rdi, rax
    je      .L1
    call    operator delete(void*)
.L1:
    add     rsp, 40
    pop     rbx
    pop     rbp
    ret
    mov     rdi, QWORD PTR [rsp]
    lea     rdx, [rsp+16]
    mov     rbx, rax
    cmp     rdi, rdx
    je      .L7
    call    operator delete(void*)
.L7:
    mov     rdi, rbx
    call    _Unwind_Resume

Now the code is a little more complex to read because code belonging to the constructor and destructor of the class is being called string.

If we now move the creation of stringthe into the loop:

#include <string>

extern int PideNumero();
extern void ExternFunc(std::string const&);

void func1()
{
  int num = PideNumero();

  for( int i=0; i<num; i++ )
  {
    std::string cad = "ABCD";
    ExternFunc(cad);
  }
}

We are left with the following:

func1():
    push    r12
    push    rbp
    push    rbx
    sub     rsp, 32
    call    PideNumero()
    test    eax, eax
    jle     .L1
    lea     rbx, [rsp+16]
    mov     r12d, eax
    xor     ebp, ebp
.L9:
    mov     DWORD PTR [rbx], 1145258561
    mov     rdi, rsp
    mov     QWORD PTR [rsp], rbx
    mov     QWORD PTR [rsp+8], 4
    mov     BYTE PTR [rsp+20], 0
    call    ExternFunc(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    mov     rdi, QWORD PTR [rsp]
    cmp     rdi, rbx
    je      .L3
    call    operator delete(void*)
.L3:
    add     ebp, 1
    cmp     r12d, ebp
    jne     .L9
.L1:
    add     rsp, 32
    pop     rbx
    pop     rbp
    pop     r12
    ret
    mov     rdi, QWORD PTR [rsp]
    lea     rdx, [rsp+16]
    mov     rbx, rax
    cmp     rdi, rdx
    je      .L7
    call    operator delete(void*)
.L7:
    mov     rdi, rbx
    call    _Unwind_Resume

The most noticeable change is that the build instructions have been moved:

mov     DWORD PTR [rbx], 1145258561
mov     QWORD PTR [rsp], rbx
mov     QWORD PTR [rsp+8], 4
mov     BYTE PTR [rsp+20], 0

and destruction of the string:

call    operator delete(void*)

Inside the loop.

In this case, you could see a decrease in performance in the case of declaring the variables inside the loop... but wait... we are talking about a string with a fixed value. What would happen if the value of the string is changed on each iteration?

Let's first see what happens if we declare the variable outside of the loop:

#include <string>

extern int PideNumero();
extern void ExternFunc(std::string const&);

void func1()
{
  int num = PideNumero();

  std::string cad;

  for( int i=0; i<num; i++ )
  {
    cad = std::string('A',i);
    ExternFunc(cad);
  }
}

Which results in:

func1():
    push    r13
    push    r12
    push    rbp
    push    rbx
    sub     rsp, 72
    lea     r13, [rsp+16]
    call    PideNumero()
    test    eax, eax
    mov     r12d, eax
    mov     QWORD PTR [rsp], r13
    mov     QWORD PTR [rsp+8], 0
    mov     BYTE PTR [rsp+16], 0
    jle     .L1
    lea     rax, [rsp+32]
    xor     ebx, ebx
    lea     rbp, [rax+16]
    jmp     .L16
.L5:
    movdqu  xmm0, XMMWORD PTR [rsp+40]
    test    rax, rax
    mov     rcx, QWORD PTR [rsp+16]
    mov     QWORD PTR [rsp], rdx
    movups  XMMWORD PTR [rsp+8], xmm0
    je      .L6
    mov     QWORD PTR [rsp+32], rax
    mov     QWORD PTR [rsp+48], rcx
.L7:
    mov     QWORD PTR [rsp+40], 0
    mov     BYTE PTR [rax], 0
    mov     rdi, QWORD PTR [rsp+32]
    cmp     rdi, rbp
    je      .L8
    call    operator delete(void*)
.L8:
    mov     rdi, rsp
    call    ExternFunc(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    add     ebx, 1
    cmp     r12d, ebx
    je      .L21
.L16:
    lea     rdi, [rsp+32]
    movsx   edx, bl
    mov     esi, 65
    mov     QWORD PTR [rsp+32], rbp
    call    std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct(unsigned long, char)
    mov     rdx, QWORD PTR [rsp+32]
    mov     rax, QWORD PTR [rsp]
    cmp     rdx, rbp
    je      .L4
    cmp     rax, r13
    jne     .L5
    movdqu  xmm0, XMMWORD PTR [rsp+40]
    mov     QWORD PTR [rsp], rdx
    movups  XMMWORD PTR [rsp+8], xmm0
.L6:
    mov     QWORD PTR [rsp+32], rbp
    mov     rax, rbp
    jmp     .L7
.L4:
    lea     rsi, [rsp+32]
    mov     rdi, rsp
    call    std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    mov     rax, QWORD PTR [rsp+32]
    jmp     .L7
.L21:
    mov     rdi, QWORD PTR [rsp]
    lea     rax, [rsp+16]
    cmp     rdi, rax
    je      .L1
    call    operator delete(void*)
.L1:
    add     rsp, 72
    pop     rbx
    pop     rbp
    pop     r12
    pop     r13
    ret
    mov     rdi, QWORD PTR [rsp]
    lea     rdx, [rsp+16]
    mov     rbx, rax
    cmp     rdi, rdx
    je      .L12
    call    operator delete(void*)
.L12:
    mov     rdi, rbx
    call    _Unwind_Resume

And now we are going to leave the string inside the loop:

#include <string>

extern int PideNumero();
extern void ExternFunc(std::string const&);

void func1()
{
  int num = PideNumero();

  for( int i=0; i<num; i++ )
  {
    std::string cad = std::string('A',i);
    ExternFunc(cad);
  }
}

The result is as follows:

func1():
    push    r12
    push    rbp
    push    rbx
    sub     rsp, 32
    call    PideNumero()
    test    eax, eax
    jle     .L1
    lea     rbp, [rsp+16]
    mov     r12d, eax
    xor     ebx, ebx
.L9:
    mov     rdi, rsp
    movsx   edx, bl
    mov     esi, 65
    mov     QWORD PTR [rsp], rbp
    call    std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct(unsigned long, char)
    mov     rdi, rsp
    call    ExternFunc(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    mov     rdi, QWORD PTR [rsp]
    cmp     rdi, rbp
    je      .L3
    call    operator delete(void*)
.L3:
    add     ebx, 1
    cmp     r12d, ebx
    jne     .L9
.L1:
    add     rsp, 32
    pop     rbx
    pop     rbp
    pop     r12
    ret
    mov     rdi, QWORD PTR [rsp]
    lea     rdx, [rsp+16]
    mov     rbx, rax
    cmp     rdi, rdx
    je      .L7
    call    operator delete(void*)
.L7:
    mov     rdi, rbx
    call    _Unwind_Resume

Para empezar vemos que si dejamos el string fuera del bucle el compilador realiza tres llamadas al destructor (al final de .L13, .L4 y .L9) mientras que si declaramos la cadena dentro del bucle únicamente se llama al destructor en dos ocasiones (final de .L9 y .L1). Además vemos que, en el caso de declarar la variable fuera del bucle, se realizan dos llamadas al constructor:

• Llamada al constructor por defecto

  mov     QWORD PTR [rsp+8], 0
  test    r12d, r12d
  mov     BYTE PTR [rsp+16], 0
  

• Y al constructor copia:

  call    std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct(unsigned long, char)
  

Luego podemos ver que el supuesto beneficio de alargar la vida de las clases realmente no tiene por qué ser tan beneficioso. En el ejemplo propuesto declarar la clase fuera del bucle origina un código más largo y más lento que si intentamos reducir el ámbito de las variables al mínimo.

Conclusión

Se podrían presentar ejemplos en los que sacar las variables fuera del bucle daría como resultado un código más rápido. Aquí únicamente pretendía demostrar que afirmar categóricamente que eso de ampliar el scope de las variables es beneficioso es un mito. Unas veces será beneficioso y otras no.

Entonces, ¿cuándo hay que optar por una solución u otra? Mi recomendación es, en este caso, intentar reducir por costumbre el ámbito al mínimo. La necesidad de ampliar la vida de las variables es algo que debería surgir de forma natural si el algoritmo no cumple con los requisitos de velocidad (requisitos que pocas veces existen) y únicamente cuando un profiler te diga que el cambio es beneficioso para tus intereses.

Lo anterior lo comento porque es ciencia cierta que cualquier programador tiene unas aptitudes para encontrar cuellos de botella propias de un hámster, sobretodo en lenguajes orientados a objetos y con código de cierta complejidad. Soy consciente de que a todos nos pasa que en un momento dado desechamos una idea porque automáticamente intentamos medir mentalmente su rendimiento y deducimos que será demasiado pobre... dejemos que sea un análisis real el que nos confirme nuestras sospechas en vez de desechar buenas ideas basándonos en teorías efímeras afectadas por nuestro humor y nuestro cansancio.

Nota final: Si este hilo tiene buena aceptación consideraré marcar la respuesta como wiki de comunidad. Aun así me gustaría que más gente aportarse su punto de vista.