Дополнительные затраты по обработке исключений связаны с выполнением блоков try. Они возникают при каждом использовании такого блока, то есть при каждой обработке исключений. Блоки try реализованы в различных компиляторах по-разному, поэтому затраты зависят еще и от компилятора. По приблизительным оценкам, использование блоков try приведет к увеличению общего объема программы и времени ее выполнения на 5-10%. И это без учета генерации исключений; сюда входят только затраты, связанные с наличием в программе блоков try. Следовательно, чтобы уменьшить затраты, необходимо избегать ненужных блоков try.

Компиляторы обычно генерируют код для спецификаций исключений примерно так же, как и для блоков try, с примерно теми же затратами. Извините, вы полагали, что спецификация исключений - это только спецификация и не приводит к генерации кода? Ну, теперь вам есть над чем подумать.

Именно затраты, связанные с генерацией исключения, и открывают суть проблемы. Однако это не должно вызывать значительного беспокойства, хотя бы потому, что исключения встречаются довольно редко, так как связаны с возникновением исключительных событий. Как следует из правила 80-20 (см. правило 16), события такого рода почти никогда не должны оказывать значительного влияния на работу программы в целом. Тем не менее, я предвижу ваш вопрос, насколько сильный удар нанесет вам возникшее исключение. Отвечу прямо: возможно, очень сильный!

По сравнению с нормальным возвратом из функции, возврат из функции при помощи генерации исключения иногда выполняется на три порядка медленнее. Достаточно мощный удар! Но он будет нанесен, только если возникнет исключение, а этого не должно происходить практически никогда. Поэтому не используйте исключения для индикации относительно обычных ситуаций, таких как завершение обхода структуры данных или завершение цикла.

Но подождите! Откуда я могу обо всем этом знать? Если многие компиляторы сравнительно недавно начали поддерживать исключения (а это на самом деле так); если разные компиляторы реализуют такую поддержку по-разному (и это так); то как же я могу сделать вывод о том, что объем программы возрастет примерно на 5-10%, что скорость программы понизится примерно настолько же и что программа будет выполняться на несколько порядков медленнее при одновременной генерации множества исключений? Такой вывод основан на предположениях и проведенных тестах (см. правило 23). Дело в том, что большинство программистов - включая производителей компиляторов - имеют недостаточный опыт работы с исключениями, так что хоть и известно, что с исключениями связаны издержки, дать им точную оценку довольно сложно.

Какими бы не были затраты на обработку исключений, не хочется платить больше, чем нужно. Чтобы уменьшить затраты, связанные с исключениями, по возможности компилируйте программы без поддержки исключений; используйте

блоки try и спецификации исключений только там, где необходимо; и генерируйте исключения только в действительно исключительных сл5аях. Если производительность программ все равно будет слишком низкой, выполните отладку программ (см. правило 16), чтобы определить, вызвано ли это поддержкой исключений. Если да, рассмотрите возможность перейти на другие компиляторы, которые более эффективно реализуют обработку исключений языка C-i-i-.

Глава 4. Эффективность

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

Но шутки в сторону. Эффективность на самом деле очень важна. Слишком большие или слишком медленные программы не находят признания, независимо от их достоинств. Так и должно быть. Ведь программы призваны помогать нам в работе, и вряд ли кто-либо станет утверждать, что медленнее значит Л5ше, что требование 32 Мб памяти вместо 16 выгоднее и что пережевывание 100 Мб дискового пространства предпочтительнее, чем поглощение только 50. Конечно, есть программы, которые имеют большой размер и используют много памяти, так как выполняют сложные вычисления, но все же в том, что у приложения слишком медленная поступь или раздутый размер , обычно виноваты плохой дизайн и небрежное программирование.

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

Материал данной главы рассматривает тему эффективности с двух направлений. Первое из них не зависит от языка программирования, и основное внимание уделяется моментам, общим для всех языков.

Язык С++ является очень привлекательным средством для реализации самых смелых идей, так как сильная поддержка инкапсуляции в нем позволяет заменить неэффективную реализацию класса ул5шенными алгоритмами и структурами данных, поддерживающих единый интерфейс.

Второе направление сконцентрировано на самом языке программирования С++. Высокопроизводительные алгоритмы и структуры данных - это замечательно, но нестабильная практика реализации может значительно снизить их эффективность. Самую коварную ошибку - создание и уничтожение слишком большого числа объектов - настолько же просто допустить, насколько распознать.