Затраты на обработку исключений в D
Каковы последствия для производительности при использовании обработки исключений в языке программирования D2? В частности:
- Что, если я не напишу код обработки исключений?
- Что если я сделаю, но исключения никогда не выдаются?
- Что если я делаю, и исключение выдается?
- Причиняет ли обработка исключений Есть ли какие-либо возможности оптимизации, которые можно упустить?
- Можно ли отключить обработку исключений, как это можно сделать во многих (большинстве?) реализациях C ++?
Я знаю, что почти все коммерческие студии разработки игр отключают обработку исключений в своих C ++ из-за влияния на производительность и увеличенное время разработки, связанное с правильной обработкой исключений. Я знаю, что D делает это последнее менее болезненным, но как насчет производительности?
Конечно, все это, вероятно, определяется реализацией, поэтому для этого вопроса, пожалуйста, обратите внимание на компилятор DMD.
1 ответ
Я не могу говорить о D или любом из его компиляторов, но я могу рассказать вам кое-что о C++, Windows и компиляторе Visual Studio. Это может помочь вам примерно понять, как работает D.
Во-первых, обработка исключений на 32- и 64-битных машинах различается. x86 ABI (пролог/эпилог, раскрутка, соглашение о вызовах) менее строгий, поэтому компилятор и сама программа должны выполнять больше работы. ABI x86-64 более строгий и ОС играет большую роль, что упрощает самой программе работу с исключениями. Если вы используете D в Windows, то он, вероятно, использует SEH (структурированная обработка исключений), как это делает C++.
Опять же, все мои ответы ниже относятся к Windows, C++ и Visual Studio.
Что если я напишу без обработки исключений код?
x86/x86-64: этот метод бесплатный.
Что, если да, но без исключений? когда-нибудь бросали?
x86: Даже если исключения не выбрасываются, приходится платить. Информация об обработке исключений помещается в TIB (блок информации о потоке), например начальная область и обработчик исключений для конкретной функции. Чтобы знать, какие объекты следует уничтожить и какие обработчики искать, поддерживается переменная области видимости. Эта переменная области видимости обновляется по мере того, как вы вводите блоки try и создаете объекты стека, имеющие деструкторы.
x86-64: Из-за более строгих правил дополнительный код отсутствует (или очень-очень минимальный). Это большое преимущество перед x86.
Что, если я это сделаю, и исключения бросил?
И на x86, и на x86-64 точно будет хит. Исключения должны быть исключительными.Не используйте их для обычного потока управления. Используйте их только для обозначения действительно исключительных, неожиданных событий. По сути, вам никогда не придется беспокоиться о стоимости исключений. Даже если они заняли 2 секунды, вам все равно, потому что они должны происходить только тогда, когда все идет наперекосяк.
При этом генерация исключений на x86-64 обходится дороже, чем их генерация на x86. Архитектура x86-64 оптимизирована для случая, когда исключения не выбрасываются, что в идеале происходит почти всегда.
Общая картина:
- Я не вижу, чтобы распространение кодов ошибок было существенно быстрее, чем обработка исключений, особенно на платформах x64.
- Я сомневаюсь, что вы когда-нибудь столкнетесь с проблемой обработки исключений, если вы не злоупотребляете исключениями.
- Если вы не уверены, вам следует измерить производительность вашего кода.