Накладные расходы на обработку исключений в D

На языке программирования D2 каковы последствия использования обработки исключений? В частности:

  • Что делать, если я не пишу код обработки исключений?
  • Что делать, но никаких исключений никогда не бросают?
  • Что делать, если исключение выбрано?
  • Выполняется ли обработка исключений при пропущенных возможностях оптимизации?
  • Можно ли отключить обработку исключений, как это может быть во многих (большинство?) реализациях С++?

Я знаю, что почти все коммерческие студии разработки игр отключают обработку исключений на своем С++ из-за последствий производительности и увеличения времени разработки, связанного с правильной обработкой исключений. Я знаю, что D делает последнее менее болезненным, но как насчет производительности?

Конечно, это, вероятно, определенная реализация, поэтому для этого вопроса, пожалуйста, сосредоточьтесь на компиляторе DMD.

Ответы

Ответ 1

Я не могу говорить о D или любом из его компиляторов, но я могу рассказать вам о С++, Windows и компиляторе Visual Studio. Это может помочь вам понять, как D делает вещи.

Во-первых, обработка исключений на 32- и 64-разрядных машинах отличается. X86 ABI (пролог/эпилог, разматывание, вызов) более слабый, поэтому компилятор и сама программа должны делать больше работы. X86-64 ABI является более строгим, и ОС играет большую роль, что облегчает работу самой программы с исключениями. Если вы используете D в Windows, то он скорее всего использует SEH (структурированная обработка исключений), как это делает С++.

Опять же, все мои ответы ниже относятся к Windows, С++ и Visual Studio.

Что делать, если я не создаю обработку исключений код?

x86/x86-64: для этого метода нет затрат.

Что делать, но никаких исключений нет когда-либо бросали?

x86: Существует стоимость, даже если исключения не выбрасываются. Информация обработки исключений вводится в TIB (блок информации потока), такой как начальная область и обработчик исключений для конкретных функций. Чтобы узнать, какие объекты нужно уничтожить и какие обработчики выполняют поиск, поддерживается переменная области видимости. Эта переменная области изменяется при вводе блоков try и создает объекты стека с деструкторами.

x86-64: Из-за более строгих правил нет дополнительного кода (или очень минимального). Это большое преимущество перед x86.

Что делать, если исключение выброшены?

На x86 или x86-64, безусловно, будет хит. Исключения должны быть исключительными, хотя. Не используйте их для регулярного потока управления. Используйте их только для того, чтобы сигнализировать действительно исключительные, неожиданные события. По сути, вам никогда не придется беспокоиться о стоимости исключений. Даже если они заняли 2 секунды, вам все равно, потому что они должны произойти только тогда, когда все идет по югу.

С учетом сказанного, бросание исключений на x86-64 стоит дороже, чем бросать их на x86. Архитектура x86-64 оптимизирована вокруг случая исключения исключений, что в идеале почти всегда.

Большая картинка:

  • Я не вижу, чтобы коды распространения распространялись быстрее, чем обработка исключений, особенно на платформах x64.
  • Я сомневаюсь, что вы когда-нибудь столкнетесь с обработкой исключений, если вы не злоупотребляете исключениями.
  • Если вы не уверены, вы должны измерить производительность вашего кода.

Ответ 2

Насколько мне известно, DMD использует все, что имеет собственный механизм на платформе. В Windows это будет Управление структурированными исключениями, которое также используется MSVС++ для реализации исключений.

В linux я полагаю, что он использует тот же механизм таблиц исключений, что и GCC. На других платформах я не знаю.

С точки зрения производительности, он, вероятно, тот же (или, по крайней мере, очень близко) к С++.