Коли питання було опубліковано, я їхав до лікаря, таксі чекало, тож я встиг тоді лише на короткий коментар. Але тепер, коли коментували, проголосували і проти, я краще додав би власну відповідь. Навіть якщо відповідь Матьє вже досить гарна.
Чи є винятки особливо повільними у C ++ порівняно з іншими мовами?
Повторний позов
"Я спостерігав за систематичною обробкою помилок в C ++ - Андрій Александреску, він стверджує, що винятки в C ++ дуже повільні".
Якщо це буквально стверджує Андрій, то раз він дуже вводить в оману, якщо не прямо помилятися. Для підвищених / кинутих винятків завжди повільно порівняно з іншими основними операціями в мові, незалежно від мови програмування . Не лише на С ++ або тим більше на С ++, ніж на інших мовах, як вказує передбачувана заява.
Загалом, в основному, незалежно від мови, дві основні мовні особливості, які на порядок повільніші за інші, оскільки вони перекладаються на виклики процедур, які обробляють складні структури даних, є
На щастя в C ++ часто можна уникнути обох у критично важливих для часу кодах.
На жаль, такої речі, як безкоштовний обід , не існує, навіть якщо ефективність C ++ за замовчуванням досить близька. :-) Для ефективності, отриманої шляхом уникнення викидів та динамічного розподілу пам'яті, як правило, досягається кодування на нижчому рівні абстракції, використовуючи С ++ як просто "кращий С". А нижча абстракція означає більшу “складність”.
Більша складність означає більше часу, витраченого на технічне обслуговування, і незначну або ніяку користь від повторного використання коду, що є реальними грошовими витратами, навіть якщо їх важко оцінити або виміряти. Тобто за допомогою C ++ можна, за бажанням, продати деяку ефективність програміста для ефективності виконання. Чи робити це, в основному є інженерним рішенням та відчуттям кишечника, оскільки на практиці можна легко оцінити та виміряти лише виграш, а не вартість.
Чи існують якісь об'єктивні показники продуктивності викидів C ++?
Так, міжнародний комітет стандартизації С ++ опублікував Технічний звіт про ефективність С ++, TR18015 .
Що означає, що винятки є «повільними»?
В основному це означає, що a throwможе зайняти дуже довгий час ™ порівняно з, наприклад, intпризначенням, завдяки пошуку обробника.
Як TR18015 обговорює у своєму розділі 5.4 “Винятки”, існує дві основні стратегії реалізації винятків,
підхід, коли кожен try-блок динамічно налаштовує зловживання винятків, так що пошук вгору по динамічному ланцюжку обробників виконується, коли виникає виняток, і
підхід, коли компілятор генерує статичні таблиці пошуку, які використовуються для визначення обробника для викинутого винятку.
Перший дуже гнучкий та загальний підхід майже вимушений у 32-розрядної Windows, тоді як у 64-розрядної версії land та * nix-land зазвичай використовується другий набагато ефективніший підхід.
Окрім того, як обговорюється у цьому звіті, для кожного підходу існує три основні сфери, де обробка винятків впливає на ефективність:
В основному, при підході динамічного обробника (32-розрядна Windows) обробка винятків впливає на tryблоки, здебільшого незалежно від мови (оскільки це вимушено схемою Windows Structured Handling Handling ), тоді як підхід до статичної таблиці має приблизно нульові витрати на try- блоків. Обговорення цього питання займе набагато більше місця та досліджень, ніж це є практичним для відповіді SO. Отже, детальніше див. У звіті.
На жаль, звіт за 2006 рік вже трохи датований станом на кінець 2012 року, і, наскільки мені відомо, немає нічого порівнянного, що є новішим.
Інша важлива перспектива полягає в тому, що вплив використання винятків на продуктивність сильно відрізняється від ізольованої ефективності допоміжних мовних функцій, оскільки, як зазначається у звіті,
"Розглядаючи обробку винятків, її слід протиставити альтернативним способам вирішення помилок".
Наприклад:
Витрати на обслуговування завдяки різним стилям програмування (правильність)
ifПеревірка виходу з ладу резервного виклику порівняно з централізованоюtry
Проблеми з кешуванням (наприклад, коротший код може поміститися в кеші)
У звіті є інший перелік аспектів, які слід врахувати, але в будь-якому випадку єдиним практичним способом отримати вагомі факти щодо ефективності виконання є, мабуть, реалізація тієї самої програми з використанням винятків, а не з використанням винятків, у межах визначеного обмеження часу розробки та з розробниками. знайомі з кожним способом, а потім ВИМІРЮЙТЕ .
Який хороший спосіб уникнути накладних винятків?
Правильність майже завжди перевершує ефективність.
Без винятків, легко може статися таке:
Деякий код P призначений для отримання ресурсу або обчислення певної інформації.
Викличний код С повинен був перевірити на успіх / помилку, але ні.
У коді після C використовується неіснуючий ресурс або недійсна інформація, що спричиняє загальний хаос.
Основною проблемою є точка (2), де за звичайною схемою зворотного коду код виклику С не змушений перевіряти.
Існує два основних підходи, які змушують таку перевірку:
Де Р безпосередньо видає виняток, коли не вдається.
Де P повертає об'єкт, який C повинен перевірити перед використанням його основного значення (інакше виняток або припинення).
Другим підходом був AFAIK, вперше описаний Бартоном та Накменом у їхній книзі * Scientific and Engineering C ++: Introduction with Advanced Techniques and Examples , де вони представили клас, що вимагає Fallowотримання «можливого» результату функції. Зараз подібний клас називається optionalбібліотекою Boost. І ви можете легко реалізувати Optionalклас самостійно, використовуючи std::vectorяк носій значення для випадку не-POD результату.
З першим підходом викличний код C не має іншого вибору, як використовувати методи обробки винятків. Однак при другому підході викличний код С може сам вирішити, чи робити ifперевірку на основі, чи загальну обробку винятків. Таким чином, другий підхід підтримує компроміс між програмістом і компромісом щодо ефективності часу виконання.
Який вплив мають різні стандарти C ++ на продуктивність винятків?
"Я хочу знати, чи все ще це справедливо для C ++ 98"
C ++ 98 був першим стандартом C ++. Для винятків він запровадив стандартну ієрархію класів виключень (на жаль, досить недосконалу). Основним впливом на продуктивність була можливість специфікацій винятків (видалених у C ++ 11), які, однак, ніколи не були повністю реалізовані основним компілятором Windows C ++ Visual C ++: Visual C ++ приймає синтаксис специфікації винятків C ++ 98, але просто ігнорує специфікації винятків.
C ++ 03 був лише технічним виправленням C ++ 98. Єдиною справді новою в C ++ 03 була ініціалізація значень . Що не має нічого спільного з винятками.
Зі стандартними вимогами C ++ 11 загальні винятки були вилучені та замінені noexceptключовим словом.
Стандарт C ++ 11 також додав підтримку для зберігання та відновлення винятків, що чудово підходить для розповсюдження винятків C ++ через зворотні дзвінки на мові C. Ця підтримка ефективно обмежує можливість збереження поточного винятку. Однак, наскільки мені відомо, це не впливає на продуктивність, за винятком тієї міри, що в нових версіях коду обробка винятків може бути простіше використовувати з обох сторін зворотного дзвінка на мові C.
