Тест Java Try / Catch Block

Я знаю, что вход в блок catch требует значительных затрат при выполнении программы, однако мне было интересно, оказал ли влияние ввод блока try {}, поэтому я начал искать в google ответ со многими мнениями, но без сравнения в все. Некоторые ответы, которые я нашел, были:

Java try/catch performance, is it recommended to keep what is inside the try clause to a minimum? Try Catch Performance Java Java try catch blocks

Однако они не ответили на мой вопрос фактами, поэтому я решил попробовать это для себя.

Вот что я сделал. У меня есть CSV-файл с этим форматом:

host;ip;number;date;status;email;uid;name;lastname;promo_code;

где все после статуса является необязательным и даже не будет иметь соответствующего; Таким образом, при синтаксическом анализе необходимо выполнить проверку, чтобы увидеть, есть ли значение, вот где мне пришла проблема try / catch.

Текущий код, который я унаследовал в моей компании, делает это:

StringTokenizer st=new StringTokenizer(line,";");  
String host = st.nextToken();
String ip = st.nextToken();
String number = st.nextToken();
String date = st.nextToken();
String status = st.nextToken();                             
String email = "";
try{
    email = st.nextToken();
}catch(NoSuchElementException e){
    email = "";
}

и он повторяет то, что он сделал для электронной почты с uid, name, фамилией и промо-кодом.

и я изменил все на:

if(st.hasMoreTokens()){
    email = st.nextToken();
}

и на самом деле это работает быстрее. При разборе файла, который не имеет дополнительных столбцов. Вот среднее время:

 --- Trying:122 milliseconds
 --- Checking:33 milliseconds

однако вот что смутило меня и причину, по которой я спрашиваю: при запуске примера со значениями для необязательных столбцов во всех 8000 строках CSV версия if () по-прежнему работает лучше, чем версия try / catch, поэтому мой вопрос

Does really the try block does not have any performance impact on my code?

Среднее время для этого примера:

--- Trying:105 milliseconds
--- Checking:43 milliseconds

Может кто-нибудь объяснить, что здесь происходит?

большое спасибо

 hectorg8711 июн. 2012 г., 15:24
@AlpeshPrajapati Я нашел эти два других поста, которые обсуждают использование try / catch в качестве механизма управления потоком. Они хороши, поэтому я хотел бы поделиться имиhere а такжеhere
 hectorg8711 июн. 2012 г., 13:08
Я не знаю, может ли это кому-нибудь помочь, но я запускаю "тест" в Java jdk_linux_x86_1.6.0.13 на моей Ubuntu 10.04 с двухъядерным процессором Intel Pentium 2,70 ГГц
 Alpesh Prajapati11 июн. 2012 г., 12:45
каждый раз проверка состояния замедляет выполнение программы. Не стоит иметь несколько операторов IF. Подход вашей компании кажется понятным. Всякий раз, когда возникают какие-либо ошибки, вы можете иметь блок catch, чтобы увидеть, о чем идет речь.
 hectorg8711 июн. 2012 г., 12:49
Не только случается очень часто, это поведение по умолчанию. Мы получим необязательные поля только во многих небольших случаях
 gexicide11 июн. 2012 г., 12:47
Я бы не стал вторым. В его случае электронная почта необязательна, поэтомуst отсутствие больше токенов не является исключительным случаем, но может случаться очень часто. Использование исключения здесь не является хорошим стилем.

Ответы на вопрос(1)

Решение Вопроса

попытка (на Java) не влияет на производительность. Компилятор не генерирует операторы VM для блока try. Он просто записывает счетчики программ, между которыми активен блок try, и присоединяет эту информацию к методу в файле класса. Затем, когда генерируется исключение, виртуальная машина разматывает стек и проверяет в каждом кадре, находится ли программный счетчик в этом кадре в соответствующем блоке try. Это (вместе со сборкой трассировки стека) довольно дорого, поэтому отлов очень дорог. Тем не менее, попробовать бесплатно :).

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

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

Упражнение try может быть быстрее в коде, где перехват срабатывает не очень часто, например, если вы входите в try 10000 раз, но только один раз, метод try будет быстрее, чем if-check. Тем не менее, это не очень хороший стиль, и ваш способ явно проверять наличие большего количества токенов должен быть предпочтительным.

 11 июн. 2012 г., 12:53
Эта конструкция try / catch очень часто используется в средах реального времени, где время выполнения очень важно, и вы не ожидаете много ошибок.
 hectorg8711 июн. 2012 г., 12:51
Время, которое я дал в своем вопросе: 1) при входе в блок catch ВСЕГДА (8000 раз * 5 столбцов) и 2) не вход в блок catch никогда, потому что дополнительные столбцы всегда есть
 11 июн. 2012 г., 12:53
если вы уже сказали «ожидайте много ошибок»; тогда вы говорите об исключительных ситуациях. В тех случаях, попытка / ловить все равно хорошо.
 11 июн. 2012 г., 12:51
хорошо, я вижу. Ну, проблема может заключаться в том, что попытка оптимизировать сложнее. Однако влияние на производительность в любом случае незначительно. Как правило, вы никогда не должны рассматривать возможность обмена с помощью try / catch для оптимизации. Просто используйте try / catch для исключительного поведения и если для регулярного потока управления. Все остальное взломать.
 hectorg8711 июн. 2012 г., 12:47
Спасибо, я действительно это понимаю, однако код, который я пробовал, говорит иначе: он выполняет попытку типа {}, что приводит к некоторым накладным расходам во время выполнения, и вот о чем мой вопрос. Я могу вставить тестовый код куда-нибудь так, Вы можете попробовать это и убедиться сами.

Ваш ответ на вопрос