В шахматном программированию рекомендуют по возможности использовать static переменные, так как они работают быстрее. Из минусов — они статические, находятся в конкретном месте памяти (а не в стеке), поэтому при рекурсивных вызовах сохраняют значение. Медленней работать будет только если выгодней использовать эту переменную как регистровую, и компилятор это понимает.

Если определить глобальный статический и локальный статический массив из int, скомпилировать его с помощью GCC в Linux и посмотреть на сгенерированный ассемблерный код, то получаем следующее:

• глобальный массив компилируется в

    .bss
a:
    .zero 40000000

• локальный массив компилируется в

.local  _ZZ1fvE1b
.comm   _ZZ1fvE1b,40000000,32

Справка по директивам ассемблера здесь: http://sourceware.org/binutils/docs-2.23.1/as/Pseudo-Ops.html#Pseudo-Ops

Однако далее, в объектном файле, оба этих массива превращаются просто в области в секции .bss. Если же инициализировать массивы (arr = { 1, 2, 3}), то оба массива таким же одинаковым образом попадают в секцию .data, и оба занимают одинаковое количество места в объектном файле.

Получается, никаких различий между этими двумя массивами нет. В Windows/MinGW имеем то же самое, только вместо .local + .comm используется директива .lcomm.

Если же вместо массивов взять собственный класс с конструктором, то становится интереснее. Из ассемблерного кода видно, что для глобального статического объекта в секцию .init_array дописывается адрес конструктора, который, видимо, будет вызван один раз при запуске программы. А для локального статического объекта происходит следующее: при каждом вызове функции производится проверка, не был ли ещё объект инициализирован, и если нет, то вызывается конструктор. Причём проверка не совсем простая и включает в себя вызовы функций __cxa_guard_acquire и __cxa_guard_release.

То есть, для нетривиальных классов (non-POD) получается, что локальная статическая переменная замедляет выполнение программы по сравнению с глобальной статической переменной.

Вывод: использовать локальные статические переменные следует только тогда, когда их тип либо встроенный, например, int, либо POD-класс (то есть, как struct в C).

Вот еще мнение Криса Касперски о локальных массивах. http://www.xakep.ru/magazine/xa/117/116/1.asp

foo()
{
int matrix[100][100]={{1,2,3},{4,5,6},{7,8,9}};
…
}

А здесь что не в порядке? Программист создает законный двухмерный массив, инициализируя малую его часть (очевидно, что остальные ячейки предполагается заполнить по ходу выполнения функции foo). Согласно Стандарту, здесь инициализируется весь массив, причем, ненулевые ячейки компиляторы инициализируют индивидуально, расходуя на каждую из них, по меньшей мере, одну машинную инструкцию. Это в идеале, а на практике компилятору MS VC необходимо 27 команд, чтобы справиться с вышеприведенным массивом. Хорошего мало, особенно, если функция foo вызывается больше одного раза. Стек не резиновый и обычно (читай — по умолчанию) потоку достается порядка 1 Мб.

За бездумное размещение массивов в стеке давно уже пора расстреливать. Ключевое слово "static", размещенное перед "int matrix", сокращает потребности в памяти и увеличивает скорость выполнения программы в несколько раз! А как быть, если статический массив нас «ну никак не устраивает»? Допустим, массив должен инициализироваться при каждом вхождении в функцию. Нет ничего проще! Размещаем исходный массив в глобальной или статической переменной, а при каждом вхождении в функцию копируем его во временный буфер, выделяемый из пула динамической памяти. Копирование, осуществляемое посредством memcpy, намного быстрее поэлементной инициализации (напоминаю, что статические массивы инициализируются на стадии компиляции, не транжиря процессорное время).