Учитывая длительные затраты на выполнение операторов if и исключений

Question

Я всегда думал, что использование «если» намного лучше (с точки зрения производительности), чем ловить исключение. Например, делая это:

User u = Users.getUser("Michael Jordan");
if(u!=null)
   System.out.println(u.getAge());

против

User u = Users.getUser("Michael Jordan");
try{
   System.out.println(u.getAge());
}catch(Exception e){
   //Do something with the exception
}

Если мы оценим это, то совершенно очевидно, что первый фрагмент быстрее второго. Это то, что я всегда думал. Но вчера парень сказал мне что-то вроде этого:

Вы когда-нибудь задумывались о том, что происходит? в тысячах казней вашего программы? Каждый раз твое исполнение проходит через "если" у вас немного (очень мало, но все же что-то) стоимость исполнения. За исключением этого не бывает Потому что это могло никогда не возникает.

Чтобы было ясно: тысячи раз выполнялся "if" против одного исключения исключений.

Я думаю, что это имеет смысл, но у меня нет никаких доказательств.

Вы можете мне помочь?

Спасибо !!

Answer 1

Никогда, НИКОГДА, не жертвуйте качеством своего кода ради производительности, пока не докажете, что вне разумных сомнений это действительно необходимо.Я очень сомневаюсь, что выполнение оператора if () когда-нибудь станет узким местом вашей программы.Если это произойдет, вам следует переписать его на языке C. В среде Java, в 99% случаев узким местом является диск ввода-вывода и / или сеть.

Answer 2

Нет. Не раз JIT включается. Скажите ему прочитать кэши трассировки .

Динамическая трассировка («путь трассировки») содержит только инструкции, результаты которых фактически используются, и исключает инструкции, следующие за взятыми ветвями (поскольку они не выполняются); динамическая трассировка может быть объединением нескольких базовых блоков. Это позволяет блоку выборки команд процессора извлекать несколько базовых блоков, не беспокоясь о ветвях в потоке выполнения.

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

Answer 3

За исключением, возможно, машинных исключений, любому обнаруженному исключению предшествует какое-то условное if. Даже NullPointerException был брошен после if(something == null) в JVM. Не беспокойтесь о производительности оператора if. Не беспокойтесь о производительности try/catch, так как, вероятно, ошибка должна возникать гораздо реже, чем при успешном выполнении. Я не думаю, что вам нужно оптимизировать, как быстро выдается ваши ошибки. : -)

Answer 4

У вас нет доказательств, потому что у вас нет дела.Это, безусловно, интересный абстрактный вопрос, если у вас есть кусок кода, который был узким местом, и вы могли бы устранить условие if, потому что одна сторона условия была очень редкой, тогда это могло бы что-то значить.Но абстрактно, выполнение этого с исключениями усложняет чтение и сопровождение кода, поэтому его не следует делать без реальной проблемы перед вами.В реальном мире это может вызвать исключение в 50% случаев.Вы не будете знать, пока у вас не будет сценария реального мира.