Net framework 5, а также среды Visual Studio 2012 и C#

540
Глава.20 .Исключения.и.управление.состоянием
скорость обработки исключений
В сообществе программистов вопросы быстродействия, связанные с обработкой 
исключений, обсуждаются очень часто и активно. Некоторые пользователи счи-
тают эту процедуру настолько медленной, что отказываются к ней прибегать. Но 
я утверждаю, что для объектно-ориентированной платформы обработка исключе-
ний обязательна. Собственно, чем ее можно заменить? Неужели вы предпочтете, 
чтобы методы возвращали значение 
true
или 
false
, чтобы сообщать об успехе 
или неудаче своей работы? Или воспользуетесь кодом ошибок типа 
enum
? В этом 
случае вы столкнетесь с худшими сторонами обоих решений. CLR и код библиотек 
классов будут генерировать исключения, а ваш код начнет возвращать код ошибок. 
В итоге вам все равно придется вернуться к необходимости обработки исключений.
Трудно сравнивать быстродействие механизма обработки исключений и более 
привычных средств уведомления об исключениях (возвращения значения 
HRESULT
, 
специальных кодов и т. п.). Если вы напишете код, который сам будет проверять 
значение, возвращаемое каждым вызванным методом, фильтровать и передавать его 
коду, вызвавшему метод, то быстродействие приложения серьезно снизится. Даже 
если оставить быстродействие в стороне, объем дополнительного кодирования и по-
тенциальная возможность ошибок окажутся неподъемными. В такой обстановке 
обработка исключений выглядит намного лучшей альтернативой.
Неуправляемым компиляторам С++ приходится генерировать код, отслежи-
вающий успешное создание объектов. Компилятор также должен генерировать код, 
который при перехвате исключения вызывает деструктор для каждого из успешно 
созданных объектов. Конечно, здорово, что компилятор принимает эту рутину на 
себя, однако он генерирует в приложении слишком много кода для ведения вну-
тренней «бухгалтерии» объектов, что негативно влияет как на объем кода, так и на 
время исполнения.
В то же время управляемым компиляторам намного легче вести учет объектов, 
поскольку память для управляемых объектов выделяется из управляемой кучи, 
за которой следит уборщик мусора. Если объект был успешно создан, а затем воз-
никло исключение, уборщик мусора, в конечном счете, освободит память, занятую 
объектом. Компилятору не приходится генерировать код для внутреннего учета 
успешно созданных объектов и последующего вызова деструктора. Это значит, что 
в сравнении с неуправляемым кодом на С++ компилятор генерирует меньше кода, 
меньше кода обрабатывается и во время выполнения, в результате быстродействие 
приложения растет.
За прошедшие годы мне приходилось пользоваться обработкой исключений на 
многих языках, в различных ОС и в системах с разными архитектурами процессора. 
В каждом случае обработка исключений была реализована по-своему, со своими 
достоинствами и недостатками. В некоторых случаях конструкции, обрабатываю-
щие исключения, компилируются прямо в метод, а в других данные, связанные 
с обработкой исключений, хранятся в связанной с методом таблице, к которой об-
ращаются только при возникновении исключений. Одни компиляторы не способны 

---

541
Скорость.обработки.исключений
выполнять подстановку кода методов, содержащих обработчики исключений, другие 
не регистрируют переменные, если в методе есть обработчик исключений.
Суть в том, что нельзя оценить величину дополнительных издержек, которые 
влечет за собой обработка исключений в приложении. В управляемом мире сделать 
такую оценку еще труднее, так как код сборки может работать на любой платформе, 
поддерживающей .NET Framework. Так, код, сгенерированный JIT-компилятором 
для обработки исключений на машине x86, будет сильно отличаться от кода, сгенери-
рованного JIT-компилятором в системах с процессором IA64 или JIT-компилятором 
из .NET Compact Framework.
Мне все же удалось протестировать некоторые мои программы с разными 
JIT-компиляторами производства Microsoft, предназначенными для внутреннего 
использования. Я неожиданно обнаружил огромную разницу в быстродействии. 
Отсюда следует, что нужно тестировать свой код на всех платформах, на которых 
предполагается его применять, и вносить соответствующие изменения. И в этом 
случае я бы не беспокоился о снижении быстродействия из-за обработки исклю-
чений. Как я уже отмечал, польза от обработки исключений намного перевешивает 
это снижение.
Если вам интересно, насколько обработка исключений снижает производитель-
ность вашего кода, используйте встроенный монитор производительности Windows. 
Показанный на рис. 20.8 снимок экрана демонстрирует счетчики, связанные с обра-
боткой исключений, которые устанавливаются при установке .NET Framework.