Чи є накладні витрати на оголошення змінної в циклі? (С ++)

Мені просто цікаво, чи не було б втрати швидкості або ефективності, якщо ви зробите щось подібне:

int i = 0;
while(i < 100)
{
    int var = 4;
    i++;
}

який заявляє int varсто разів. Мені здається, що це було б, але я не впевнений. чи було б практичніше / швидше зробити це замість цього:

int i = 0;
int var;
while(i < 100)
{
    var = 4;
    i++;
}

або вони однакові, швидкісні та ефективні?

Простір стеку для локальних змінних зазвичай виділяється в області функцій. Таким чином, ніяких налаштувань покажчика стека не відбувається всередині циклу, просто присвоюючи 4 var. Тому ці два фрагменти мають однакові накладні витрати.

Для примітивних типів і типів POD це не має значення. Компілятор виділить простір стека для змінної на початку функції та звільнить його, коли функція повернеться в обох випадках.

Для типів класів, що не є POD, які мають нетривіальні конструктори, це ЗМІНИТЬ різницю - у такому випадку виведення змінної поза цикл буде викликати конструктор і деструктор лише один раз, а оператор присвоєння кожну ітерацію, тоді як поміщати її всередину циклу буде викликати конструктор і деструктор для кожної ітерації циклу. Залежно від того, що роблять конструктор, деструктор та оператор присвоєння класу, це може бути або не бути бажаним.

Вони обидва однакові, і ось як ви можете це дізнатись, подивившись, що робить компілятор (навіть без оптимізації, встановленої на високу):

Подивіться, що робить компілятор (gcc 4.0) на ваших простих прикладах:

1.c:

main(){ int var; while(int i < 100) { var = 4; } }

gcc -S 1.c

1.s:

_main:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $24, %esp
    movl    $0, -16(%ebp)
    jmp L2
L3:
    movl    $4, -12(%ebp)
L2:
    cmpl    $99, -16(%ebp)
    jle L3
    leave
    ret

2.c

main() { while(int i < 100) { int var = 4; } }

gcc -S 2.c

2.s:

_main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp
        movl    $0, -16(%ebp)
        jmp     L2
L3:
        movl    $4, -12(%ebp)
L2:
        cmpl    $99, -16(%ebp)
        jle     L3
        leave
        ret

З них видно дві речі: по-перше, код однаковий в обох.

По-друге, сховище для var виділяється поза циклом:

         subl    $24, %esp

І нарешті, єдине, що є у циклі, - це призначення та перевірка стану:

L3:
        movl    $4, -12(%ebp)
L2:
        cmpl    $99, -16(%ebp)
        jle     L3

Що приблизно настільки ефективно, наскільки ви можете бути, не видаляючи цикл повністю.

У наші дні краще оголосити це всередині циклу, якщо це не константа, оскільки компілятор зможе краще оптимізувати код (зменшуючи область змінної).

EDIT: Ця відповідь зараз здебільшого застаріла. З ростом посткласичних компіляторів випадки, коли компілятор не може це зрозуміти, стають рідкісними. Я все ще можу їх побудувати, але більшість людей класифікують конструкцію як поганий код.

Більшість сучасних компіляторів оптимізують це для вас. Слід сказати, що я скористався вашим першим прикладом, оскільки вважаю його більш читабельним.

Для вбудованого типу, швидше за все, не буде різниці між 2 стилями (можливо, аж до згенерованого коду).

Однак, якщо змінна є класом з нетривіальним конструктором / деструктором, цілком може бути велика різниця у вартості виконання. Як правило, я б застосовував змінну до цикла (щоб область була якомога меншою), але якщо це виявиться перфектним, я хотів би перемістити змінну класу за межі цикла. Однак для цього потрібен додатковий аналіз, оскільки семантика шляху оди може змінитися, тому це можна зробити лише за умови, якщо це дозволяє сематика.

Класу RAII може знадобитися така поведінка. Наприклад, для належного управління доступом до файлу може знадобитися створити та знищити клас, який керує доступом до файлу на кожній ітерації циклу.

Припустимо, у вас є LockMgrклас, який отримує критичний розділ при його побудові та випускає його при знищенні:

while (i< 100) {
    LockMgr lock( myCriticalSection); // acquires a critical section at start of
                                      //    each loop iteration

    // do stuff...

}   // critical section is released at end of each loop iteration

зовсім відрізняється від:

LockMgr lock( myCriticalSection);
while (i< 100) {

    // do stuff...

}

Обидві петлі мають однакову ефективність. Вони обидва займуть нескінченну кількість часу :) Може бути непоганою ідеєю збільшити i всередині петель.

Одного разу я провів кілька тестів на ефективність, і на мій подив, виявив, що випадок 1 насправді був швидшим! Я припускаю, що це може бути тому, що оголошення змінної всередині циклу зменшує її область дії, тому вона стає вільною раніше. Однак це було дуже давно, на дуже старому компіляторі. Я впевнений, що сучасні компілятори краще справляються з оптимізацією відхилень, але все одно не завадить тримати якомога коротший обсяг змінних.

#include <stdio.h>
int main()
{
    for(int i = 0; i < 10; i++)
    {
        int test;
        if(i == 0)
            test = 100;
        printf("%d\n", test);
    }
}

Код вище завжди друкує 100 10 разів, що означає, що локальна змінна всередині циклу виділяється лише один раз за кожен виклик функції.

Єдиний спосіб бути впевненим - це встановити час. Але різниця, якщо вона є, буде мікроскопічною, тому вам знадобиться потужний великий цикл синхронізації.

Точніше, перший - кращий стиль, оскільки він ініціалізує змінну var, а інший залишає її неініціалізованою. Це та вказівка ​​щодо того, що слід визначати змінні якомога ближче до місця їх використання, означає, що першій формі зазвичай слід надавати перевагу.

Маючи лише дві змінні, компілятору, ймовірно, буде призначено регістр для обох. Ці реєстри в будь-якому випадку є, тому це не вимагає часу. В обох випадках є 2 інструкції з запису і один регістр.

Я думаю, що в більшості відповідей не вистачає основного моменту, який слід розглянути, а саме: "Чи зрозуміло це", і очевидно, що, судячи з усього обговорення, це факт; ні, це не так. Я б припустив, що в більшості кодових циклів ефективність майже не є проблемою (якщо ви не розраховуєте для мардера), тому справді єдине питання полягає в тому, що виглядає більш розумним, читабельним і ремонтопридатним - у цьому випадку я рекомендую змінна спереду та за межами циклу - це просто робить її зрозумілішою. Тоді такі люди, як ти, і я навіть не потурбуюсь витрачати час на перевірку в Інтернеті, чи дійсно це чи ні.

це неправда, є накладні витрати, однак накладні витрати, які можуть нехтувати.

Незважаючи на те, що, ймовірно, вони опиняться там же в стеці, він все одно призначає це. Він призначить місце пам’яті в стеку для цього int, а потім звільнить його в кінці}. Не в сенсі вільного купи в сенсі він перемістить sp (покажчик стека) на 1. А у вашому випадку, якщо врахувати, що він має лише одну локальну змінну, він просто зрівняє fp (покажчик на кадр) і sp

Короткою відповіддю буде: НЕ ДОГЛЯДАЙТЕ, ЩОБ ТАК РАБОТИ ПРИБЛИЖНО ТЕЖ.

Але спробуйте прочитати більше про те, як організовано стек. У моїй студентській школі були досить хороші лекції з цього питання. Якщо ви хочете прочитати більше, перевірте тут http://www.cs.utk.edu/~plank/plank/classes/cs360/360/notes/Assembler1/lecture.html