C++ / Exceptions и производительность

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

Мой опыт работы включает в себя несколько лет разработки под разные встроенные системы, где производительность постоянно приходится учитывать при написании кода (системы реального времени, обрабатывающие большой объём информации — скорости процессора и памяти там никогда не бывало «много»). Соответственно, в этой среде программисты обычно достаточно хорошо представляют себе, какие накладные расходы несёт (или не несёт) та или иная возможность, предоставляемая языком С++. К примеру, поддержка namespace — никаких дополнительных затрат вообще; RTTI — дополнительная секция с именами классов/структур с их type_info (итоговый бинарник увеличивается в размере, но кодогенерацию это не затрагивает); и т.п. Как (не на всех платформах) реализована поддержка исключений мы и посмотрим.

Используемые инструменты: древний front-end от EDG ^[1] для преобразования кода на C++ в код на С и Artistic Style ^[2] для форматирования полученных С-файлов (иначе их читать невозможно). Про front-end от EDG надо сказать особо — это именно тот frond-end, который встраивается в компиляторы Intel, компиляторы Texas Instruments и т.п. Так как поддержать все возможности C++ — очень непростая задача (по сравнению с реализацией всех возможностей языка С), то на некоторых платформах происходит трансляция С++ кода в идентичный код на С, а уже этот код «скармливается» С-компилятору. Front-end используется не самый свежий, но для понимания подойдёт.

Итак, возьмём достаточно простой текстовый код (имена и константы выбраны специально такими, чтобы их легко находить в обработанном листинге):

struct AAAAA {   int a;   virtual void process();    AAAAA() { a = 1234; }   virtual ~AAAAA() {} };  struct BBBBB : AAAAA {   virtual void process();      BBBBB() { a = 5678; }   virtual ~BBBBB() {} };  // forward declaration int bar();  int foo() {   BBBBB b1;   b1.a = bar();   b1.process();    BBBBB b2;   b2.a = bar();   b2.process();    return b1.a + b2.a; } 

Всё очень просто — два inline конструктора/деструктора, пара виртуальных функций, пара вызовов внешней функции.

Вот получаемый код без поддержки исключений (результат обработан AStyle'ом). Простыня, но это необходимо:

#line 1 "1.cpp" struct __T9639768; struct AAAAA; #line 9 struct BBBBB; struct __T9639768 {     short d;     short i;     void (*f)(); }; #line 1 struct AAAAA {     int a;     struct __T9639768 *__vptr; }; #line 9 struct BBBBB {     struct AAAAA __b_AAAAA; }; #line 17 extern int bar__Fv(void);  extern int foo__Fv(void); #line 10 extern void process__5BBBBBFv(struct BBBBB *const); extern struct __T9639768 __vtbl__5AAAAA[3]; extern struct __T9639768 __vtbl__5BBBBB[3]; #line 19 int foo__Fv(void) {   auto int __T9722792;     auto struct BBBBB b1;      auto struct BBBBB b2; #line 21     { {             ((b1.__b_AAAAA).__vptr) = __vtbl__5AAAAA;             ((b1.__b_AAAAA).a) = 1234;         } ((b1.__b_AAAAA).__vptr) = __vtbl__5BBBBB;         ((b1.__b_AAAAA).a) = 5678;     }     ((b1.__b_AAAAA).a) = (bar__Fv());     process__5BBBBBFv((&b1));      { {             ((b2.__b_AAAAA).__vptr) = __vtbl__5AAAAA;             ((b2.__b_AAAAA).a) = 1234;         } ((b2.__b_AAAAA).__vptr) = __vtbl__5BBBBB;         ((b2.__b_AAAAA).a) = 5678;     }     ((b2.__b_AAAAA).a) = (bar__Fv());     process__5BBBBBFv((&b2));     {          __T9722792 = ((((b1.__b_AAAAA).a)) + (((b2.__b_AAAAA).a)));         {             ((b2.__b_AAAAA).__vptr) = __vtbl__5BBBBB;             { {                     ((b2.__b_AAAAA).__vptr) = __vtbl__5AAAAA;                 }             }         } {             ((b1.__b_AAAAA).__vptr) = __vtbl__5BBBBB;             { {                     ((b1.__b_AAAAA).__vptr) = __vtbl__5AAAAA;                 }             }         }         return __T9722792;     } } 

Хорошо видно, как «конструируется» каждый объект, как реализованы vtable/наследование, что конструкторы/деструкторы всё ещё inline, а у C-компилятора всё ещё есть вся информация, чтобы эффективно оптимизировать данный код. Также отметим, что получившийся C-код занимает 72 строки, и примерно 1.6kB.

Теперь этот же исходник оттранслируем с поддержкой исключений.

Результат смотреть здесь: C-эквивалент размером в 253 строки и 8.5 kB ^[3]. Здесь я это выкладывать не буду, ограничусь основной функцией (бывшей int foo()) с комментариями некоторых моментов:

int foo__Fv(void) {   static struct __T9641460 __T9653776[2] = {{((void (*)())__dt__5BBBBBFv),((unsigned short)0U),((unsigned short)65535U),((unsigned char)0U)},{((void (*)())__dt__5BBBBBFv),((unsigned short)1U),((unsigned short)0U),((unsigned char)0U)}};     auto void *__T9731464[2];     auto int __T9733536;     auto struct #line 20             __T9643156 __T9734356;     auto struct BBBBB b1;      auto struct BBBBB b2;     (__T9734356.next) = __curr_eh_stack_entry;     __curr_eh_stack_entry = (&__T9734356);     (__T9734356.kind) = ((unsigned char)1U);     (((__T9734356.variant).function).regions) = ((struct __T9641460 *)__T9653776);     (((__T9734356.variant).function).obj_table) = ((void **)__T9731464);     ((( #line 25           __T9734356.variant).function).saved_region_number) = __eh_curr_region;     __eh_curr_region = ((unsigned short)65535U); #line 21     __ct__5BBBBBFv((&b1));     (((void **)__T9731464)[0U]) = ((void *)(&b1));     __eh_curr_region = ((unsigned short)0U);     ((b1.__b_AAAAA).a) = (bar__Fv());     process__5BBBBBFv((&b1));      __ct__5BBBBBFv((&b2));     (((void **)__T9731464)[1U]) = ((void *)(&b2));     __eh_curr_region = ((unsigned short)1U);     ((b2.__b_AAAAA).a) = (bar__Fv());     process__5BBBBBFv((&b2)); {          __T9733536 = ((((b1.__b_AAAAA).a)) + (((b2.__b_AAAAA).a)));         __eh_curr_region = ((unsigned short)0U);         __dt__5BBBBBFv((&b2), 2);         __eh_curr_region = ((unsigned short)65535U);         __dt__5BBBBBFv((&b1), 2);         {             __eh_curr_region = ((((__T9734356.variant).function).saved_region_number));             __curr_eh_stack_entry = #line 29                 ((__T9734356.next));             return __T9733536;         }     } } 

Главные изменения:

• конструкторы перестали быть inline (появились вызовы __ct__5BBBBBFv),
• аналогичная ситуация с деструкторами (__dt__5BBBBBFv),
• в коде теперь отслеживается, какой из объектов уже сконструирован (или уже удалён), а какой ещё нет — так как нужно знать, деструкторы каких объектов требуется вызвать, если произойдёт исключение,
• код конструкторов/деструкторов усложнился (функции __dt__5BBBBBFv/ct__5BBBBBFv, смотреть по ссылке),

Самая беда именно с первыми двумя пунктами — логика конструкторов/деструкторов усложнилась настолько, что front-end выносит их в отдельные функции. Понятно почему — встраивание их (inline) приведёт к сильному увеличению кода каждой функции, где используются объекты типа BBBB. Но следствием этого станет то, что оптимизатор C-компилятора сгенерирует существенно менее производительный код (у нас появились дополнительные вызовы и проверки в коде).

То есть: просто включение поддержки исключений привело и к увеличению объёма конечного бинарного файла, и к замедлению работы всех функций, внутри которых происходит конструирование объектов (за исключением самых тривиальных).

Собственно, это и есть основная причина, по которой для embedded разработки поддержка исключений по умолчанию выключена — за неё приходится платить, даже если ей реально не пользоваться.

PS: это всё, конечно, не означает, что «исключения — это плохо!» или «используйте коды возврата вместо исключений!». Просто каждый инструмент хорош для своей задачи.
PPS: поддержка обработки ошибочных ситуаций в embedded разработке, конечно же есть и активно используется. Она обычно не использует C++ exceptions, это тема отдельной статьи.

Автор: qehgt