Изучая тему исключений решил проверить так ли страшны исключения как их малюют. Написал две тестовые програмки:

//exception.cpp


//standard.cpp


Общая задача для двух программ - узнать об ошибке в функции и увеличить переменную. Т.е. пытаемся определить насколько исключения будут медленными, если одну и ту же функцию вызывать несколько миллионов раз. По умолчанию стоит 100 миллионов. Решил также сравнить как на циклы влияет оптимизация и компиляторы gcc и msvc между собой.



Из результатов видно, что оптимизация в gcc вообще никак не влияет на скорость. Зато в msvc оптимизация работает, но только для стандартных способов проверки. Т.е. оптимизации исключений не проводятся ни в gcc, ни в msvc.

При стандартном способе проверки (без exception'ов) оптимизация дает хороший прирост в скорости для msvc, по сравнению с gcc.

Однако с исключениями в msvc творится что-то странное, они ну очень тормозные по сравнению с gcc. Мне пришлось отказаться от 100 миллионов циклов в пользу 1 миллиона. Но если умножить лучший результат на 100, то мне бы пришлось ожидать 481 секунду. Терпения не хватило. Я не исключаю того, что возможно для msvc есть какие-то ключи для компилятора связаные с выбором реализации исключений. 

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

Вполне возможно, что я мог где-то накосячить в исходниках и все результаты можно пустить коту под хвост, поэтому буду рад конструктивной критике. Может быть я вообще не правильно использую исключения 

ты их неправильно используешь  

дело в том, что обычно, программа редко занимается обработкой исключений, но во все функции способные бросить исключение (а в некоторых случаях во все функции), передается дополнительная информация, вот это и нужно измерять, а ты просто используешь исключения вместо return, а это не обычный способ их использования 

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

не всегда. И даже не в большинстве случаев.


это как называется? "Какой плохой компилятор хватит оптимизировать?" 

Это понятно. Моей целью было замерить ту самую скорость из-за которой не советуют использовать исключения вместо кодов ошибок (напр. Bjarne Straustrup).

Добавлено через 3 минуты и 23 секунды

Я хотел оптимизации именно циклов (развертка циклов и т.п.).

SABROG, не занимайся ерундой, хочешь использовать - используй. А сидеть и пытаться вычислить наносекунду разницы это реально извращение.


volatile зачем юзаешь?

Понимаешь в чем дело, мне нравятся исключения за то, что это хороший механизм не только для отладки, но и за более секьюрной идентификации ошибки вместо многоэтажных if'ов или case'ов. К тому же код выглядит более причесанным и легкочитаемым. И действительно хочется использовать исключения вместо кодов возвратов где только можно. Но везде пишут о том, какое это опасное оружие не в тех руках и при неправильном применении. Вот и хочется мне самому понять как все-таки стоит проектировать приложение с исключениями и в каких методых его стоит использовать. А если уж промахнусь, то кого винить за тормоза.



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

Может конечно и ерундой занимаюсь, но ведь придут и другие люди с тем же вопросом.

1-й вариант - функция не бросает исключения


работает примерно 1.5 сек

второй вариант - ф-я бросает исключение при каждом 100000-м вызове

работает за 1.6 сек.

Добавлено через 1 минуту и 46 секунд
то есть реально исключение обрабатывается только 100 раз, и на скорость сама его обработка не влияет, 5%-я разница это и есть стоимость использования исключений

проясняю ситуацию
в современной программе практически НЕВОЗМОЖНО избавиться от оверхеда, накладываемого исключениями
почему?
потому, что вы вызываете функции сторонних библиотек и те в свою очередь делают то-же самое.
т.о. вы можете объявить throw() весьма ограниченное число собственных функций, которые либо не вызывают других функций вообще (включая неявные) либо вызывают заведомо функции не бросающие исключения. Иначе вы рискуете остаться без вызова деструкторов локальных объектов, т.к. данная функция не будет добавлена в таблицу размотки исключения. Смею напомнить, что стандартный new может выбросить исключение.
Т.о. даже если вы НЕ ловите исключения (или ловите их в саом конце - в main) вы НЕ МОЖЕТЕ промежуточные функции объявит throw().

точнее тут
http://forum.vingrad.ru/forum/topic-229145/kw-exception.html

Это сообщение отредактировал(а) J0ker - 25.9.2008, 20:15

Joker, вижу вроде написал что-то умное, но написал на каком-то, только тебе, понятном языке.

В принципе тема себя исчерпала. Я вижу, что люди почему-то встают на сторону исключений, хотя способ которым я их использовал является стандартным способом проверки ошибки. Факт остается фактом, как не используй исключения, а они медленней стандартных методов проверки. Другое дело, что в одном случае они медленней в 100 раз, а в другом на 5%, а это уже о чем то говорит.

Механизм исключений по определению предназначен для обработки исключительных (т.е. редко возникающих) ситуаций. Если одна и та же ошибка то и дело возникает в каком-то цикле, то это уже не исключительная ситуация, и способы её обработки нужны соответствующие.

ну если выразиться по простому - любая функция объявляющая локальные объекты требующие разрушения и (функция-же) содержащая после этого вызов(ы) не throw() функций - (как минимум) всегда содержит в прологе регистрацию в таблице размотки. Т.о. этот оверхед по времени и по объему кода неизбежен. Оверхед catch-а и по времени и по объему ничтожный. Плюс, конечно-же, оверхед по объему от наличия самого стека размотки.
Сам-же процесс обработки исключения не во всех компиляторах оптимизирован, и поэтому тесты дают гигантский разброс. Отсуствие хорошей оптимизации связано с тем, что механизм исключений это НЕ РУТИННЫЙ механизм завершения блока, и должен использоваться для индикации действительно исключительных ситуаций.
Вобщем я дуаю что оценка в 5% - вполне достоверна...

если бы функция func выполнялась достаточно долго, то там и 5-ти процентной разницы небыло-бы

просто надо учесть, что регистрация вызывается практически для каждой функции на каждом входе