Исключения C++ и производительность (2)

Предыдущее: Исключения C++ и производительность (1.1)

Итак, я знаю, что в общем случае при обработке сгенерированного исключения происходят дополнительные затраты процессорного времени. Какие они и чем мне это грозит?

Исключения и программист

В книге Херба Саттера "Exceptional C++" есть пример разработки класса Stack, в котором операция извлечения значения с верхушки стека была реализована примерно так:

T& Stack<T>::Top ()
{
  if (0 == vused_)
  {
    throw "empty stack";
  }

  return data_[vused_ - 1];
}

То есть, если стек пуст, то программа выбросит исключение, чтобы уведомить пользователя (программиста) о том, что в стеке ничего нет. Хорошо, но предположим, что есть некоторый класс, который реализован по принципу pull и регулярно тянет из стека данные до тех пор, пока не получит исключение. Затем стек заполняется, и класс снова тянет данные из него... и так всё время. Конечно, этот пример притянут за уши, но в реальной жизни такие конструкции всё же встречаются.

Интересный момент в том, что соотношение успешных и неуспешных вызовов Top() может быть различным. Например, стек может заполняться одним элементам и затем передаваться на обработку. В этом случае, исключение будет генерироваться в 50% вызовов. Или можно заполнять стек 100 элементами, тогда исключение будет генерироваться всего в 1% вызовов. Хотелось бы знать разницу между такими сценариями.
* * *
Я написал простенькую программку, с помощью которой хочу увидеть зависимость накладных расходов от количества генерируемых исключений. Я знаю, что компилятор GCC использует статический подход, поэтому по идее до вызова исключения производительность программы не должна изменяться.

Программа циклически выполняет вызовы функции bool func(), которая в случае "ошибки" возвращает false или генерирует исключение. В случае, когда "ошибки" нет, функция просто возвращает true. Количество вызовов — MaxNum (у меня равно 10,000,000). Ошибка генерируется с помощью генератора случайных чисел, процент "ошибочных" ситуаций задается в командной строке. Ведется подсчет количества "ошибок", в конце выводится статистика. Для сравнения производительности программы с исключениями и без них добавлен макрос _USE_EXCEPTIONS, который нужно задавать при компиляции.

1. #include <cstdlib>
2. #include <iostream>
3.  
4. using std::cout;
5. using std::endl;
6.  
7. const size_t MaxNum = 10000000;
8. float Percent = 0;
9. float Divisor = 0;
10.  
11. bool func ()
12. #ifdef _USE_EXCEPTIONS
13. throw (int)
14. #else
15. throw ()
16. #endif
17. {
18.   const int x = rand();
19.   if (x > (RAND_MAX - RAND_MAX/Divisor))
20.   {
21. #ifdef _USE_EXCEPTIONS
22.     throw 1;
23. #else
24.     return false;
25. #endif
26.   }
27.  
28.   return true;
29. }
30.  
31. int main (int argc, char **argv)
32. {
33.   Percent = atof(argv[1]);
34.   Divisor = 100 / Percent;
35.  
36.   srand(1);
37.  
38.   size_t trueCounter = 0;
39.   size_t falseCounter = 0;
40.  
41.   size_t n = MaxNum;
42.   while (n--)
43.   {
44.     try
45.     {
46.       const bool r = func();
47. #ifndef _USE_EXCEPTIONS
48.       if (r)
49. #endif
50.       {
51.         trueCounter += 1;
52.       }
53. #ifndef _USE_EXCEPTIONS
54.       else
55.       {
56.         falseCounter += 1;
57.       }
58. #endif
59.     }
60.     catch (int)
61.     {
62.       falseCounter += 1;
63.     }
64.   }
65.  
66.   cout << "false: " << falseCounter << endl;
67.   cout << "true:  " << trueCounter << endl;
68.   cout << "percentage ~" << float(falseCounter) / MaxNum * 100 << endl;
69.   return 0;
70. }
71.  

Исходный файл можно взять здесь. Для чистоты эксперимента программа компилируется с включенной оптимизацией. использовался GCC версии 4.4.
Без исключений:
g++ -O3 a.cpp
С исключениями:
g++ -O3 -D_USE_EXCEPTIONS a.cpp

Запуск программы:
./a.out <PERCENT>, где PERCENT — процент ошибки. Программа запускалась для значений: 0.00001 (типа нуль), 0.001, 0.1, 1, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100.

Время выполнения программы представлено в таблице:

Процент ошибки PERCENT (%)	Без исключений (сек)	С исключениями (сек)
0	0,110	0,110
0.001	0,110	0,110
0.1	0,110	0,130
1	0,110	0,340
10	0,130	2,430
20	0,150	4,680
30	0,170	6,950
40	0,180	9,380
50	0,175	11,450
60	0,180	13,950
70	0,170	16,150
80	0,150	18,350
90	0,130	20,550
100	0,110	22,700

Из таблицы видно, что вариант программы, не использующий исключений, ведет себя более-менее стабильно. Есть горб в середине графика, но это из-за промахов мимо кэша.

А вот время выполнения программы с исключениями линейно зависит от количества генерируемых исключений. При отсутствии или малом количестве генерируемых исключений время выполнения соизмеримо с программой, не использующей исключения. Затем при увеличении количества исключений время выполнения программы растет. Это подтверждает утверждение, что при использовании статического метода оверхэд не появляется, пока исключение не сгенерировано. Последняя строка (100%) соответсвует клиническому случаю, когда программа вообще не использует возвращаемые коды ошибок, а управляется только посредством исключений (я своими глазами видел проект с таким кодом).

Аналогичные тесты я запускал и для компилятора cl.exe из Microsoft Visual Studio Express. Вид графиков был аналогичным, разница была лишь в цифрах и соотношениях. Например, для строки 100% разница была не в 200 раз как здесь, а всего в 120. Надо еще добавить, что компилятор от Microsoft использует смесь табличного и динамического подхода, и каждый блок try-catch реализован через работу со стеком. Это привело к тому, что небольшая разница по времени выполнения наблюдалась даже при отсутствии "ошибок".

В общем, разница видна невооруженным взглядом. Даже при 10% "ошибок" разница во времени больше, чем в 20 раз. И дальше разница только увеличивается. Какой вывод можно сделать?

Думаю, ответ прячется в самом названии механизма exceptions — "исключения", то есть события, которые происходят настолько редко, что являются исключениями из правил обычного поведения программы. Если вероятность возникновения некоего события в программе равна 50%, то вряд ли такое событие можно назвать исключением, скорее это часть нормального поведения. А вот, если предполагаемое событие может возникать очень редко, и что самое главное, если возникновение этого события делает невалидным текущий сценарий поведения и приводит к его завершению, то такое событие можно отнести к исключениям. Следовательно, механизм исключений лучше всего использовать для различного рода критических событий, типа нехватки памяти, недоступность каких-то других ресурсов, критические ошибки доступа к ячейкам памяти и т. п.
* * *
Возвращаясь к примеру с классом Stack, можно попытаться оценить частоту возникновения исключения и реализовать тот или иной подход, в зависимости от результатов. Но, думаю, в данном случае не нужно городить огород и достаточно защитить вызов метода Top() дополнительным вызовом метода isEmpty(), который возвращает true, если стек пустой:

Stack stack;
...
if (!stack.isEmpty())
{
  T element = stack.Top();
  ...
}
...

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

Заключение

Я не думаю, что в ближайшее время подходы к реализации обработки исключений компиляторами существенно изменятся. Подозреваю даже, что подходы примерно одинаковы в реализациях других языков программирования (если это не так, любопытно было бы ознакомиться с альтернативой). Поэтому мое мнение такое: механизм исключений — это нужная и полезная вещь, но использовать её нужно с умом, исходить не только из оценок производительности, но и с точки зрения логики кода.

Закончить можно цитатой из MSDN, которая в данном случае подходит как нельзя кстати:

Because of the nature of exception handling and the extra overhead involved, exceptions should be used only to signal the occurrence of unusual or unanticipated program events. Exception handlers should not be used to redirect the program's normal flow of control. For example, an exception should not be thrown in cases of potential logic or user input errors, such as the overflow of an array boundary. In these cases, simply returning an error code may be simpler and more concise. Judicious use of exception handling constructs makes your program easier to maintain and your code more readable.

UPDATE (15 дек 2010): Вопрос о том, когда нужно и не нужно использовать исключения, также рассматривается в книге Э. Ханта и Д. Томаса "Программист-прагматик", гл. 24 "Случаи, в которых используются исключения".