Почему это различие в производительности? (Ловля исключения)
ДА!
Извините за вопли:-)
Управление версиями не только полезно для отката версий. Это даст большую безопасность против развертывания более старых версий файлов или случайно перезаписи более новых версий с более старыми версиями и т.д.
Одна вещь, к которой я только теперь привыкаю, это действительно полезно, способность перейти и объединить различные версии. Если у Вас есть крайний срок, подходя, но Вы работаете над новой возможностью, это не готово к прайм-тайму, можно просто перейти, прежде чем Вы начали добавлять ту опцию. Создайте поставляемую версию без той функции и объедините те два после передач крайнего срока без проблем.
7 ответов
Нет способ, который должен занять секунду для 1900 итераций, если вы не работаете в отладчике. Запускать тесты производительности под отладчиком - плохая идея.
РЕДАКТИРОВАТЬ: Обратите внимание, что это не случай перехода к выпуску build - это случай работы без отладчика; например, нажатие Ctrl-F5 вместо F5 .
Сказав это, создание исключений, когда вы можете очень легко их избежать, является также плохой идеей.
Мое мнение о производительности исключений : если вы используете их по назначению, они не должны ' t вызывают значительные проблемы с производительностью , если только вы в любом случае не попали в какую-то катастрофическую ситуацию (например, вы пытаетесь сделать сотни тысяч вызовов веб-служб, и сеть не работает).
Исключения для отладчиков дорого обходятся - конечно, в Visual Studio, во всяком случае - из-за решения, взламывать ли отладчик и т.д., и, вероятно, выполнять какой-либо анализ стека, который в противном случае не нужен. В любом случае они все еще несколько дороги, но вы не должны бросать их достаточно, чтобы заметить. Еще предстоит раскрутка стека, поиск соответствующих обработчиков catch и т. Д. - но это должно происходить только тогда, когда что-то изначально не так.
РЕДАКТИРОВАТЬ: Конечно, генерирование исключения по-прежнему даст вам меньше итераций в секунду (хотя 35000 все еще очень низкое число - я бы ожидал более 100K), потому что вы почти ничего не делаете в случае без исключения. Давайте посмотрим на два:
Неисключительная версия тела цикла
- Присвойте значение null переменной
- Проверьте, имеет ли переменная значение null; это так, поэтому вернитесь к началу цикла
(Как упоминалось в комментариях, вполне возможно, что JIT все равно оптимизирует это ...)
Версия исключения:
- Присвойте значение null переменной
- Переменная разыменования
Версия тела цикла без исключения
- Присвойте переменной значение NULL
- Проверьте, является ли переменная значением NULL; это так, поэтому вернитесь к началу цикла
(Как упоминалось в комментариях, вполне возможно, что JIT все равно оптимизирует это ...)
Версия исключения:
- Присвойте значение null переменной
- Переменная разыменования
Версия тела цикла без исключения
- Присвойте переменной значение NULL
- Проверьте, является ли переменная значением NULL; это так, поэтому вернитесь к началу цикла
(Как упоминалось в комментариях, вполне возможно, что JIT все равно оптимизирует это ...)
Версия исключения:
- Присвойте значение null переменной
- Переменная разыменования
- Неявная проверка на аннулирование
- Создание объекта исключения
- Проверка наличия обработчиков отфильтрованных исключений для вызова
- Поиск в стеке блока catch для перехода к
- Проверка любых блоков finally
- Разветвляйтесь соответствующим образом
Неудивительно, что вы видите снижение производительности?
Теперь сравните это с более распространенной ситуацией, когда вы выполняете целую кучу работы, возможно, ввод-вывод, создание объектов и т.д. - и возможно генерируется исключение. Тогда разница становится намного менее значительной.
Посетите блог Криса Брамме , уделив особое внимание разделу Производительность и тенденции , чтобы узнать, почему исключения работают медленно. Их не зря называют «исключениями»: они не должны происходить очень часто.
Этот популярный вопрос также может оказаться полезным: Насколько медленны исключения .NET?
Здесь есть еще один фактор. ЕСЛИ у вас есть файл .pdb на месте в исполняющем каталоге, то при возникновении исключения среда выполнения .NET прочитает файл .pdb, чтобы получить номер строки кода для включения в трассировку стека исключения. На это уходит довольно много времени. Попробуйте свой первый метод (с исключением) с файлом .pdb и без него в исполняющем каталоге.
Я провел простой временной тест с и без .pdb в качестве ответа на другой вопрос, здесь .
Оптимизация что компилятор выполняет, и я считаю, что это могло быть «устранение мертвого кода»; также, в зависимости от используемого вами компилятора, последняя программа на самом деле выполняет то, что ассемблеры называют «бездействием».
В моих тестах "исключительный" код не такой медленный - намного медленнее, но не настолько. Отличие заключается в создании объекта Exception (или, точнее, NullReferenceException). Самая медленная часть в нем - получение строки сообщения об исключении - есть внутренний вызов GetResourceString - и получение трассировки стека.
Это ужасный микротест.
] Последний «оптимизированный» цикл имеет в качестве инварианта времени компиляции, что test всегда равен нулю, поэтому нет необходимости даже беспокоиться о компиляции при попытке присваивания. Фактически вы тестируете пустой цикл, каждый раз вызывая исключение.
Действительно хороший jit может даже полностью удалить цикл, отметив, что цикл не имеет тела, следовательно, никаких побочных эффектов, кроме увеличения счетчика, и что сам счетчик не используется (это маловероятно, поскольку такая оптимизация будет иметь маленькая полезность в реальном мире). Вы все еще можете делать десятки тысяч их в секунду на скромном оборудовании.