Оказывает ли количество исключенных исключений влияние производительности на код try?

Question

Я читал довольно часто, что использование try-catch довольно медленное по сравнению с обычным кодом. Теперь мне интересно, влияет ли количество обнаруженных исключений на производительность кода или нет.

Так

try{ 
    ... 
} 
catch(StrangeException e){ 
    ... 
} 

медленнее, чем

try{ 
    ... 
} 
catch(StrangeException e){ 
    ... 
} 
catch(MysteriousException e){ 
    ... 
} 
catch(FrighteningException e){ 
    ... 
} 

?

Конечно, я имею в виду только код в предложении try и если исключение не обнаружено.

Answer 1

Стоимость блока try/catch по существу равна нулю, если не исключены какие-либо исключения. Количество предложений catch не имеет значения.

Стоимость исключений происходит только, когда они на самом деле вышвырнут:

• Построение объекта исключения очень дорого из-за стоимости fillInStackTrace() шага. Это должно создать и инициализировать структуру данных, содержащую ключевые сведения обо всех кадрах в текущем потоке стека. В худшем случае их могут быть тысячи.

• Бросание и перехватывание исключений немного дорого. В худшем случае JVM должен выполнить эквивалент instanceof для каждого предложения catch каждого блока try/catch. Именно там, где множество статей catch может повлиять на производительность.

Answer 2

Единственный способ узнать наверняка с вопросами производительности - это тщательно протестировать его самостоятельно.

Но если вы попросили меня сделать ставку, я бы поспорил, что это не делает ощутимой разницы вообще, и что даже использование try/catch против использования не имеет большого значения, поскольку на самом деле исключений нет (чего они не должны быть, в обычном случае).

Answer 3

То, что вы прочитали, неверно. Значительные накладные расходы возникают, когда исключение действительно бросается - обычно накладные расходы минимальны, когда нет исключений. Единственным исключением является то, что это может сильно повлиять на inlining - поэтому, если у вас есть метод, который вызывается в узком цикле, вы можете обнаружить, что он не встает, если он имеет блоки try/catch. Точно так же наличие кода может повлиять на когерентность кэша и другие тонкости ... но в большинстве ситуаций это не будет быть узким местом.

Я не думаю, что у меня есть видел реальную ситуацию, когда исключения не получаются, но наличие блоков try/catch было проблемой производительности. Как всегда, вы должны написать самый чистый код, который вы можете, и проверить, как он работает. Только подумайте о том, чтобы искривить идеальный дизайн по форме по соображениям производительности, когда у вас есть четкое свидетельство того, что изменения необходимы как , так и.

Answer 4

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

Когда возникает исключение, JVM знает, как перейти к последовательности байт-кода, которая реализует предложение catch, просматривая исключение в таблице, которая является частью байт-кода класса. В общем, каждый метод, который ловит исключение, связан с таблицей исключений, которая является частью файла класса, вместе с байт-кодом метода. В таблице исключений имеется запись для каждого исключения, которое было обнаружено каждым блоком try. Каждая запись содержит: начальную и конечную точки, смещение счетчика программы (ПК) в последовательности байт-кода для перехода к ней и постоянный индекс пула выбранного типа исключения (то есть класс).

Если во время выполнения метода выбрано исключение, JVM выполняет поиск по таблице исключений для соответствия. Сопоставления встречаются, если текущий ПК находится в пределах диапазона, указанного в записи, и если класс исключенного класса является указанным в записи (или является его подклассом).

Таким образом, ответ на ваш вопрос зависит от способа реализации этого поиска. Насколько мне известно, JVM просматривает таблицу в том же порядке, в котором записи появляются в таблице, и когда первое совпадение найдено, JVM устанавливает ПК в новое место и продолжает выполнение оттуда.

Я думаю, что если у вас нет МНОГО исключений, вы бы не заметили значительного воздействия, но если бы я был вами, и если бы эта проблема была для меня критической, я бы сравнил ее с конкретным JVM, который вы используете ,

Ori

Answer 5

Я помню, как читал, что кто-то проверил это и обнаружил, что производительность на самом деле была затронута в этом случае, даже если вы, вероятно, не было бы ожидать, что это будет. (Быстрый поиск в Google не показывает его, хотя я не помню, сколько было блоков catch, или какая версия Java была найдена.)