Как исключения влияют на производительность в Java?

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

Я думаю, это не совсем ответ на вопрос. Я полагаю, что «обычная» мудрость создания медленных исключений была верна в более ранних версиях java (<1.4). Для создания исключения требуется, чтобы виртуальная машина создала всю трассировку стека. С тех пор многое изменилось в виртуальной машине, чтобы ускорить процесс, и, вероятно, это одна из областей, которая была улучшена.

Почему исключения должны возвращаться медленнее, чем обычно?

Пока вы не распечатываете трассировку стека на терминал, не сохраняете ее в файл или что-то подобное, блок catch не выполняет больше работы, чем другие блоки кода. Итак, я не могу представить, почему throw new my_cool_error () должен быть таким медленным.

Хороший вопрос, и я с нетерпением жду дополнительной информации по этой теме!

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

Но все же - я считаю, что это следует рассматривать только как необходимое зло, в крайнем случае. Причина, по которой Джон сделал это, - имитировать функции на других языках, которые (пока) недоступны в JVM. Вы НЕ должны иметь привычки использовать исключения для потока управления. Особенно по соображениям производительности! Как вы сами упомянули в № 2, вы рискуете таким образом замаскировать серьезные ошибки в своем коде, и новым программистам будет труднее поддерживать его.

Микробенчмарки в Java на удивление сложно сделать правильно (мне сказали), особенно когда вы попадаете на территорию JIT, поэтому я действительно сомневаюсь, что использование исключений быстрее, чем «возврат» в реальной жизни. Например, я подозреваю, что в вашем тесте где-то между 2 и 5 кадрами стека? Теперь представьте, что ваш код будет вызываться компонентом JSF, развернутым JBoss. Теперь у вас может быть трассировка стека длиной в несколько страниц.

Возможно, вы могли бы опубликовать свой тестовый код?

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

Я провел некоторое тестирование производительности с JVM 1.5, и использование исключений было как минимум в 2 раза медленнее. В среднем: время выполнения тривиально небольшого метода увеличилось более чем втрое (3 раза) с исключениями. Тривиально маленький цикл, который должен был перехватить исключение, показал двукратное увеличение собственного времени.

Я видел похожие числа в производственном коде, а также в микро-тестах.

Исключения обязательно следует использовать НЕТ для всего, что часто вызывается. Выбрасывание тысячи исключений в секунду привело бы к огромному горлышку бутылки.

Например, использование «Integer.ParseInt (...)» для поиска всех неверных значений в очень большом текстовом файле - очень плохая идея. (Я видел производительность этого служебного метода убийство в производственном коде)

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

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

Это зависит от того, как реализованы исключения. Самый простой способ - использовать setjmp и longjmp. Это означает, что все регистры ЦП записываются в стек (что уже занимает некоторое время) и, возможно, необходимо создать некоторые другие данные ... все это уже происходит в инструкции try. Оператор throw должен раскрутить стек и восстановить значения всех регистров (и возможные другие значения в виртуальной машине). Таким образом, try и throw одинаково медленны, и это довольно медленно, однако, если исключение не генерируется, выход из блока try в большинстве случаев не требует времени вообще (поскольку все помещается в стек, который очищается автоматически, если метод существует).

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

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

Также большое значение имеет то, что вы делаете в блоке try. Если вы открываете блок try и никогда не вызываете какой-либо метод из этого блока try, блок try будет очень быстрым, так как JIT может фактически обрабатывать throw как простой goto. Ему не нужно ни сохранять состояние стека, ни раскручивать стек при возникновении исключения (ему нужно только перейти к обработчикам catch). Однако это не то, что вы обычно делаете. Обычно вы открываете блок try, а затем вызываете метод, который может вызвать исключение, верно? И даже если вы просто используете блок try в своем методе, что это будет за метод, который не вызывает никаких других методов? Будет ли он просто подсчитывать число? Тогда зачем вам исключения? Есть гораздо более элегантные способы регулирования выполнения программы. Для чего угодно, кроме простой математики, вам придется вызвать внешний метод, и это уже разрушает преимущество локального блока try.

См. Следующий тестовый код:

public class Test {
    int value;


    public int getValue() {
        return value;
    }

    public void reset() {
        value = 0;
    }

    // Calculates without exception
    public void method1(int i) {
        value = ((value + i) / i) << 1;
        // Will never be true
        if ((i & 0xFFFFFFF) == 1000000000) {
            System.out.println("You'll never see this!");
        }
    }

    // Could in theory throw one, but never will
    public void method2(int i) throws Exception {
        value = ((value + i) / i) << 1;
        // Will never be true
        if ((i & 0xFFFFFFF) == 1000000000) {
            throw new Exception();
        }
    }

    // This one will regularly throw one
    public void method3(int i) throws Exception {
        value = ((value + i) / i) << 1;
        // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
        // an AND operation between two integers. The size of the number plays
        // no role. AND on 32 BIT always ANDs all 32 bits
        if ((i & 0x1) == 1) {
            throw new Exception();
        }
    }

    public static void main(String[] args) {
        int i;
        long l;
        Test t = new Test();

        l = System.currentTimeMillis();
        t.reset();
        for (i = 1; i < 100000000; i++) {
            t.method1(i);
        }
        l = System.currentTimeMillis() - l;
        System.out.println(
            "method1 took " + l + " ms, result was " + t.getValue()
        );

        l = System.currentTimeMillis();
        t.reset();
        for (i = 1; i < 100000000; i++) {
            try {
                t.method2(i);
            } catch (Exception e) {
                System.out.println("You'll never see this!");
            }
        }
        l = System.currentTimeMillis() - l;
        System.out.println(
            "method2 took " + l + " ms, result was " + t.getValue()
        );

        l = System.currentTimeMillis();
        t.reset();
        for (i = 1; i < 100000000; i++) {
            try {
                t.method3(i);
            } catch (Exception e) {
                // Do nothing here, as we will get here
            }
        }
        l = System.currentTimeMillis() - l;
        System.out.println(
            "method3 took " + l + " ms, result was " + t.getValue()
        );
    }
}

Результат:

method1 took 972 ms, result was 2
method2 took 1003 ms, result was 2
method3 took 66716 ms, result was 2

Замедление от блока try слишком мало, чтобы исключить мешающие факторы, такие как фоновые процессы. Но блокировка захвата убила все и сделала его в 66 раз медленнее!

Как я уже сказал, результат не будет таким плохим, если вы поместите try / catch и throw в один и тот же метод (method3), но это особая оптимизация JIT, на которую я бы не положился. И даже при использовании этой оптимизации бросок по-прежнему довольно медленный. Так что я не знаю, что вы здесь пытаетесь сделать, но определенно есть лучший способ сделать это, чем использовать try / catch / throw.

Некоторое время назад я написал класс для проверки относительной производительности преобразования строк в целые числа, используя два подхода: (1) вызвать Integer.parseInt () и перехватить исключение или (2) сопоставить строку с регулярным выражением и вызвать parseInt () только в случае удачного совпадения. Я использовал регулярное выражение наиболее эффективным способом (т. Е. Создавая объекты Pattern и Matcher перед переходом в цикл), и я не печатал и не сохранял трассировки стека из исключений.

Для списка из десяти тысяч строк, если бы все они были действительными числами, подход parseInt () был в четыре раза быстрее, чем подход регулярного выражения. Но если только 80% строк были действительными, регулярное выражение было в два раза быстрее, чем parseInt (). И если 20% были действительными, то есть исключение было сгенерировано и перехвачено в 80% случаев, регулярное выражение было примерно в двадцать раз быстрее, чем parseInt ().

Я был удивлен результатом, учитывая, что подход регулярных выражений обрабатывает действительные строки дважды: один раз для совпадения и еще раз для parseInt (). Но выброс и перехват исключений с лихвой компенсировали это. Такая ситуация вряд ли будет часто возникать в реальном мире, но если это произойдет, вам определенно не следует использовать технику перехвата исключений. Но если вы только проверяете ввод пользователя или что-то в этом роде, обязательно используйте подход parseInt ().

Не знаю, связаны ли эти темы, но однажды я хотел реализовать один трюк, полагаясь на трассировку стека текущего потока: я хотел узнать имя метода, который запускал создание экземпляра внутри экземпляра класса (да, идея безумная, Я полностью отказался от этого). Итак, я обнаружил, что вызов Thread.currentThread().getStackTrace() выполняется очень сильно медленно (из-за собственного метода dumpThreads, который он использует внутри).

Итак, Java Throwable, соответственно, имеет собственный метод fillInStackTrace. Я думаю, что описанный ранее блок killer-catch каким-то образом запускает выполнение этого метода.

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

В Scala некоторые функциональные возможности компилируются в JVM с использованием ControlThrowable, который расширяет Throwable и переопределяет его fillInStackTrace следующим образом:

override def fillInStackTrace(): Throwable = this

Итак, я адаптировал тест выше (количество циклов уменьшилось на десять, моя машина немного медленнее :):

class ControlException extends ControlThrowable

class T {
  var value = 0

  def reset = {
    value = 0
  }

  def method1(i: Int) = {
    value = ((value + i) / i) << 1
    if ((i & 0xfffffff) == 1000000000) {
      println("You'll never see this!")
    }
  }

  def method2(i: Int) = {
    value = ((value + i) / i) << 1
    if ((i & 0xfffffff) == 1000000000) {
      throw new Exception()
    }
  }

  def method3(i: Int) = {
    value = ((value + i) / i) << 1
    if ((i & 0x1) == 1) {
      throw new Exception()
    }
  }

  def method4(i: Int) = {
    value = ((value + i) / i) << 1
    if ((i & 0x1) == 1) {
      throw new ControlException()
    }
  }
}

class Main {
  var l = System.currentTimeMillis
  val t = new T
  for (i <- 1 to 10000000)
    t.method1(i)
  l = System.currentTimeMillis - l
  println("method1 took " + l + " ms, result was " + t.value)

  t.reset
  l = System.currentTimeMillis
  for (i <- 1 to 10000000) try {
    t.method2(i)
  } catch {
    case _ => println("You'll never see this")
  }
  l = System.currentTimeMillis - l
  println("method2 took " + l + " ms, result was " + t.value)

  t.reset
  l = System.currentTimeMillis
  for (i <- 1 to 10000000) try {
    t.method4(i)
  } catch {
    case _ => // do nothing
  }
  l = System.currentTimeMillis - l
  println("method4 took " + l + " ms, result was " + t.value)

  t.reset
  l = System.currentTimeMillis
  for (i <- 1 to 10000000) try {
    t.method3(i)
  } catch {
    case _ => // do nothing
  }
  l = System.currentTimeMillis - l
  println("method3 took " + l + " ms, result was " + t.value)

}

Итак, результаты такие:

method1 took 146 ms, result was 2
method2 took 159 ms, result was 2
method4 took 1551 ms, result was 2
method3 took 42492 ms, result was 2

Видите ли, единственная разница между method3 и method4 состоит в том, что они генерируют разные виды исключений. Да, method4 все еще медленнее, чем method1 и method2, но разница гораздо более приемлемая.

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

  public static int parseUnsignedInt(String s, int defaultValue) {
    final int strLength = s.length();
    if (strLength == 0)
      return defaultValue;
    int value = 0;
    for (int i=strLength-1; i>=0; i--) {
      int c = s.charAt(i);
      if (c > 47 && c < 58) {
        c -= 48;
        for (int j=strLength-i; j!=1; j--)
          c *= 10;
        value += c;
      } else {
        return defaultValue;
      }
    }
    return value < 0 ? /* übergebener wert > Integer.MAX_VALUE? */ defaultValue : value;
  }

Пока вы применяете оба метода к «действительным» данным, они оба будут работать примерно с одинаковой скоростью (даже несмотря на то, что Integer.parseInt справляется с обработкой более сложных данных). Но как только вы попытаетесь проанализировать недопустимые данные (например, проанализировать "abc" 1 000 000 раз), разница в производительности должна стать существенной.

К сожалению, мой ответ слишком длинный, чтобы публиковать его здесь. Итак, позвольте мне подвести итог и отослать вас к http://www.fuwjax.com/how-slow-are-java-exceptions/ за подробностями.

Настоящий вопрос здесь не в том, «Насколько медленны« сбои, сообщаемые как исключения »по сравнению с« кодом, который никогда не дает сбоев »?» как вы могли поверить принятому ответу. Вместо этого следует задать вопрос: «Насколько медленны« отказы, сообщаемые как исключения »по сравнению с отказами, сообщаемыми другими способами?» Как правило, два других способа сообщения об ошибках - либо с помощью контрольных значений, либо с помощью оболочек результатов.

Значения Sentinel - это попытка вернуть один класс в случае успеха и другой - в случае неудачи. Вы можете думать об этом почти как о возврате исключения, а не о его генерации. Для этого требуется общий родительский класс с объектом успеха, а затем выполнение проверки «instanceof» и пары приведений, чтобы получить информацию об успехе или неудаче.

Оказывается, что рискуя безопасностью типов, значения Sentinel быстрее, чем исключения, но только примерно в 2 раза. Может показаться, что это много, но это вдвое покрывает только разницу в реализации. На практике этот коэффициент намного ниже, поскольку наши методы, которые могут потерпеть неудачу, намного интереснее, чем несколько арифметических операторов, как в примере кода в другом месте на этой странице.

С другой стороны, Result Wrappers вообще не жертвуют безопасностью типов. Они объединяют информацию об успехах и неудачах в один класс. Таким образом, вместо instanceof они предоставляют isSuccess () и геттеры для объектов успешного и неудачного выполнения. Однако результирующие объекты примерно в 2 раза больше помедленнее, чем при использовании исключений. Оказывается, каждый раз создавать новый объект-оболочку намного дороже, чем иногда генерировать исключение.

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

Исключения безопаснее, чем дозорные, быстрее, чем объекты результата, и менее удивительны, чем любой другой. Я не предлагаю, чтобы try / catch заменяли if / else, но исключения - это правильный способ сообщить об ошибке, даже в бизнес-логике.

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

К вашему сведению, я расширил эксперимент, который сделал Меки:

method1 took 1733 ms, result was 2
method2 took 1248 ms, result was 2
method3 took 83997 ms, result was 2
method4 took 1692 ms, result was 2
method5 took 60946 ms, result was 2
method6 took 25746 ms, result was 2

Первые 3 такие же, как у Меки (мой ноутбук явно медленнее).

method4 идентичен method3 за исключением того, что он создает new Integer(1), а не выполняет throw new Exception().

method5 похож на method3 за исключением того, что он создает new Exception(), не выбрасывая его.

method6 похож на method3 за исключением того, что он генерирует предварительно созданное исключение (переменную экземпляра), а не создает новое.

В Java большая часть затрат на создание исключения - это время, затрачиваемое на сбор трассировки стека, которая происходит при создании объекта исключения. Фактические затраты на создание исключения, хотя и велики, значительно меньше затрат на создание исключения.

Я изменил ответ @Mecki выше, чтобы метод 1 возвращал логическое значение и проверку в вызывающем методе, поскольку вы не можете просто заменить исключение ничем. После двух запусков method1 все еще был либо самым быстрым, либо таким же быстрым, как method2.

Вот снимок кода:

// Calculates without exception
public boolean method1(int i) {
    value = ((value + i) / i) << 1;
    // Will never be true
    return ((i & 0xFFFFFFF) == 1000000000);

}
....
   for (i = 1; i < 100000000; i++) {
            if (t.method1(i)) {
                System.out.println("Will never be true!");
            }
    }

и результаты:

Бег 1

method1 took 841 ms, result was 2
method2 took 841 ms, result was 2
method3 took 85058 ms, result was 2

Бег 2

method1 took 821 ms, result was 2
method2 took 838 ms, result was 2
method3 took 85929 ms, result was 2

Производительность исключений в Java и C# оставляет желать лучшего.

Как программистов, это заставляет нас жить по правилу «исключения должны возникать нечасто» просто по практическим соображениям производительности.

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

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

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

Вот образец кода, который сравнивает производительность исключения с производительностью, возвращаемой ошибкой.

public class TestIt {

int value;


public int getValue() {
    return value;
}

public void reset() {
    value = 0;
}

public boolean baseline_null(boolean shouldfail, int recurse_depth) {
    if (recurse_depth <= 0) {
        return shouldfail;
    } else {
        return baseline_null(shouldfail,recurse_depth-1);
    }
}

public boolean retval_error(boolean shouldfail, int recurse_depth) {
    if (recurse_depth <= 0) {
        if (shouldfail) {
            return false;
        } else {
            return true;
        }
    } else {
        boolean nested_error = retval_error(shouldfail,recurse_depth-1);
        if (nested_error) {
            return true;
        } else {
            return false;
        }
    }
}

public void exception_error(boolean shouldfail, int recurse_depth) throws Exception {
    if (recurse_depth <= 0) {
        if (shouldfail) {
            throw new Exception();
        }
    } else {
        exception_error(shouldfail,recurse_depth-1);
    }

}

public static void main(String[] args) {
    int i;
    long l;
    TestIt t = new TestIt();
    int failures;

    int ITERATION_COUNT = 100000000;


    // (0) baseline null workload
    for (int recurse_depth = 2; recurse_depth <= 10; recurse_depth+=3) {
        for (float exception_freq = 0.0f; exception_freq <= 1.0f; exception_freq += 0.25f) {            
            int EXCEPTION_MOD = (exception_freq == 0.0f) ? ITERATION_COUNT+1 : (int)(1.0f / exception_freq);            

            failures = 0;
            long start_time = System.currentTimeMillis();
            t.reset();              
            for (i = 1; i < ITERATION_COUNT; i++) {
                boolean shoulderror = (i % EXCEPTION_MOD) == 0;
                t.baseline_null(shoulderror,recurse_depth);
            }
            long elapsed_time = System.currentTimeMillis() - start_time;
            System.out.format("baseline: recurse_depth %s, exception_freqeuncy %s (%s), time elapsed %s ms\n",
                    recurse_depth, exception_freq, failures,elapsed_time);
        }
    }


    // (1) retval_error
    for (int recurse_depth = 2; recurse_depth <= 10; recurse_depth+=3) {
        for (float exception_freq = 0.0f; exception_freq <= 1.0f; exception_freq += 0.25f) {            
            int EXCEPTION_MOD = (exception_freq == 0.0f) ? ITERATION_COUNT+1 : (int)(1.0f / exception_freq);            

            failures = 0;
            long start_time = System.currentTimeMillis();
            t.reset();              
            for (i = 1; i < ITERATION_COUNT; i++) {
                boolean shoulderror = (i % EXCEPTION_MOD) == 0;
                if (!t.retval_error(shoulderror,recurse_depth)) {
                    failures++;
                }
            }
            long elapsed_time = System.currentTimeMillis() - start_time;
            System.out.format("retval_error: recurse_depth %s, exception_freqeuncy %s (%s), time elapsed %s ms\n",
                    recurse_depth, exception_freq, failures,elapsed_time);
        }
    }

    // (2) exception_error
    for (int recurse_depth = 2; recurse_depth <= 10; recurse_depth+=3) {
        for (float exception_freq = 0.0f; exception_freq <= 1.0f; exception_freq += 0.25f) {            
            int EXCEPTION_MOD = (exception_freq == 0.0f) ? ITERATION_COUNT+1 : (int)(1.0f / exception_freq);            

            failures = 0;
            long start_time = System.currentTimeMillis();
            t.reset();              
            for (i = 1; i < ITERATION_COUNT; i++) {
                boolean shoulderror = (i % EXCEPTION_MOD) == 0;
                try {
                    t.exception_error(shoulderror,recurse_depth);
                } catch (Exception e) {
                    failures++;
                }
            }
            long elapsed_time = System.currentTimeMillis() - start_time;
            System.out.format("exception_error: recurse_depth %s, exception_freqeuncy %s (%s), time elapsed %s ms\n",
                    recurse_depth, exception_freq, failures,elapsed_time);              
        }
    }
}

}

И вот результаты:

baseline: recurse_depth 2, exception_freqeuncy 0.0 (0), time elapsed 683 ms
baseline: recurse_depth 2, exception_freqeuncy 0.25 (0), time elapsed 790 ms
baseline: recurse_depth 2, exception_freqeuncy 0.5 (0), time elapsed 768 ms
baseline: recurse_depth 2, exception_freqeuncy 0.75 (0), time elapsed 749 ms
baseline: recurse_depth 2, exception_freqeuncy 1.0 (0), time elapsed 731 ms
baseline: recurse_depth 5, exception_freqeuncy 0.0 (0), time elapsed 923 ms
baseline: recurse_depth 5, exception_freqeuncy 0.25 (0), time elapsed 971 ms
baseline: recurse_depth 5, exception_freqeuncy 0.5 (0), time elapsed 982 ms
baseline: recurse_depth 5, exception_freqeuncy 0.75 (0), time elapsed 947 ms
baseline: recurse_depth 5, exception_freqeuncy 1.0 (0), time elapsed 937 ms
baseline: recurse_depth 8, exception_freqeuncy 0.0 (0), time elapsed 1154 ms
baseline: recurse_depth 8, exception_freqeuncy 0.25 (0), time elapsed 1149 ms
baseline: recurse_depth 8, exception_freqeuncy 0.5 (0), time elapsed 1133 ms
baseline: recurse_depth 8, exception_freqeuncy 0.75 (0), time elapsed 1117 ms
baseline: recurse_depth 8, exception_freqeuncy 1.0 (0), time elapsed 1116 ms
retval_error: recurse_depth 2, exception_freqeuncy 0.0 (0), time elapsed 742 ms
retval_error: recurse_depth 2, exception_freqeuncy 0.25 (24999999), time elapsed 743 ms
retval_error: recurse_depth 2, exception_freqeuncy 0.5 (49999999), time elapsed 734 ms
retval_error: recurse_depth 2, exception_freqeuncy 0.75 (99999999), time elapsed 723 ms
retval_error: recurse_depth 2, exception_freqeuncy 1.0 (99999999), time elapsed 728 ms
retval_error: recurse_depth 5, exception_freqeuncy 0.0 (0), time elapsed 920 ms
retval_error: recurse_depth 5, exception_freqeuncy 0.25 (24999999), time elapsed 1121   ms
retval_error: recurse_depth 5, exception_freqeuncy 0.5 (49999999), time elapsed 1037 ms
retval_error: recurse_depth 5, exception_freqeuncy 0.75 (99999999), time elapsed 1141   ms
retval_error: recurse_depth 5, exception_freqeuncy 1.0 (99999999), time elapsed 1130 ms
retval_error: recurse_depth 8, exception_freqeuncy 0.0 (0), time elapsed 1218 ms
retval_error: recurse_depth 8, exception_freqeuncy 0.25 (24999999), time elapsed 1334  ms
retval_error: recurse_depth 8, exception_freqeuncy 0.5 (49999999), time elapsed 1478 ms
retval_error: recurse_depth 8, exception_freqeuncy 0.75 (99999999), time elapsed 1637 ms
retval_error: recurse_depth 8, exception_freqeuncy 1.0 (99999999), time elapsed 1655 ms
exception_error: recurse_depth 2, exception_freqeuncy 0.0 (0), time elapsed 726 ms
exception_error: recurse_depth 2, exception_freqeuncy 0.25 (24999999), time elapsed 17487   ms
exception_error: recurse_depth 2, exception_freqeuncy 0.5 (49999999), time elapsed 33763   ms
exception_error: recurse_depth 2, exception_freqeuncy 0.75 (99999999), time elapsed 67367   ms
exception_error: recurse_depth 2, exception_freqeuncy 1.0 (99999999), time elapsed 66990 ms
exception_error: recurse_depth 5, exception_freqeuncy 0.0 (0), time elapsed 924 ms
exception_error: recurse_depth 5, exception_freqeuncy 0.25 (24999999), time elapsed 23775  ms
exception_error: recurse_depth 5, exception_freqeuncy 0.5 (49999999), time elapsed 46326 ms
exception_error: recurse_depth 5, exception_freqeuncy 0.75 (99999999), time elapsed 91707 ms
exception_error: recurse_depth 5, exception_freqeuncy 1.0 (99999999), time elapsed 91580 ms
exception_error: recurse_depth 8, exception_freqeuncy 0.0 (0), time elapsed 1144 ms
exception_error: recurse_depth 8, exception_freqeuncy 0.25 (24999999), time elapsed 30440 ms
exception_error: recurse_depth 8, exception_freqeuncy 0.5 (49999999), time elapsed 59116   ms
exception_error: recurse_depth 8, exception_freqeuncy 0.75 (99999999), time elapsed 116678 ms
exception_error: recurse_depth 8, exception_freqeuncy 1.0 (99999999), time elapsed 116477 ms

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

Для сравнения, производительность исключений зависит не от глубины вызова, а от частоты возникновения исключений. Однако деградация по мере увеличения частоты исключений гораздо более драматична. При частоте ошибок всего 25% код работал в 24 РАЗ медленнее. При частоте ошибок 100% версия исключения работает почти в 100 РАЗ медленнее.

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

Я расширил ответы, данные @Mecki и @incarnate, без заполнения трассировки стека для Java.

С Java 7+ мы можем использовать Throwable(String message, Throwable cause, boolean enableSuppression,boolean writableStackTrace). Но для Java6 см. мой ответ на этот вопрос

// This one will regularly throw one
public void method4(int i) throws NoStackTraceThrowable {
    value = ((value + i) / i) << 1;
    // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
    // an AND operation between two integers. The size of the number plays
    // no role. AND on 32 BIT always ANDs all 32 bits
    if ((i & 0x1) == 1) {
        throw new NoStackTraceThrowable();
    }
}

// This one will regularly throw one
public void method5(int i) throws NoStackTraceRuntimeException {
    value = ((value + i) / i) << 1;
    // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
    // an AND operation between two integers. The size of the number plays
    // no role. AND on 32 BIT always ANDs all 32 bits
    if ((i & 0x1) == 1) {
        throw new NoStackTraceRuntimeException();
    }
}

public static void main(String[] args) {
    int i;
    long l;
    Test t = new Test();

    l = System.currentTimeMillis();
    t.reset();
    for (i = 1; i < 100000000; i++) {
        try {
            t.method4(i);
        } catch (NoStackTraceThrowable e) {
            // Do nothing here, as we will get here
        }
    }
    l = System.currentTimeMillis() - l;
    System.out.println( "method4 took " + l + " ms, result was " + t.getValue() );


    l = System.currentTimeMillis();
    t.reset();
    for (i = 1; i < 100000000; i++) {
        try {
            t.method5(i);
        } catch (RuntimeException e) {
            // Do nothing here, as we will get here
        }
    }
    l = System.currentTimeMillis() - l;
    System.out.println( "method5 took " + l + " ms, result was " + t.getValue() );
}

Вывод с Java 1.6.0_45, на Core i7, 8 ГБ ОЗУ:

method1 took 883 ms, result was 2
method2 took 882 ms, result was 2
method3 took 32270 ms, result was 2 // throws Exception
method4 took 8114 ms, result was 2 // throws NoStackTraceThrowable
method5 took 8086 ms, result was 2 // throws NoStackTraceRuntimeException

Таким образом, все еще методы, возвращающие значения, работают быстрее по сравнению с методами, генерирующими исключения. ИМХО, мы не можем разработать четкий API, просто используя возвращаемые типы как для успешных, так и для ошибок. Методы, которые генерируют исключения без трассировки стека, в 4-5 раз быстрее обычных исключений.

Обновлено: NoStackTraceThrowable.java Спасибо @Greg

public class NoStackTraceThrowable extends Throwable { 
    public NoStackTraceThrowable() { 
        super("my special throwable", null, false, false);
    }
}

Алексей Шипилев сделал очень тщательный анализ, в котором он тестировал исключения Java при различных комбинациях условий:

• Недавно созданные исключения против предварительно созданных исключений
• Трассировка стека включена или отключена
• Запрошена трассировка стека или никогда не запрашивалась
• Пойманный на верхнем уровне против переброшенного на каждом уровне против прикованного / обернутого на каждом уровне
• Различные уровни глубины стека вызовов Java
• Нет оптимизации встраивания против экстремального встраивания против настроек по умолчанию
• Пользовательские поля прочитаны или не прочитаны

Он также сравнивает их с производительностью проверки кода ошибки на различных уровнях частоты ошибок.

Выводы (дословно цитируемые из его сообщения) были:

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

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

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

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

5. Если мы устраним оба эффекта, то затраты на производительность исключений будут такими же, как у местного филиала. Как бы красиво это ни звучало, это не означает, что вы должны использовать исключения в качестве обычного потока управления, потому что в этом случае вы во власти оптимизирующего компилятора! вы должны использовать их только в действительно исключительных случаях, когда частота исключения амортизирует - это возможные несчастливые затраты на повышение фактического исключение.

6. Оптимистичное практическое правило выглядит так: частота 10 ^ -4 для исключений достаточно исключительна. Это, конечно, зависит от веса самих исключений, точных действий, предпринятых в обработчиках исключений и т. д.

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

Мое мнение о скорости исключений по сравнению с программной проверкой данных.

Многие классы имели преобразователь String в значение (сканер / парсер), а также уважаемые и известные библиотеки;)

обычно имеет форму

class Example {
public static Example Parse(String input) throws AnyRuntimeParsigException
...
}

имя исключения является только примером, обычно не отмечено (время выполнения), поэтому объявление throws - это только моя картинка

иногда существует вторая форма:

public static Example Parse(String input, Example defaultValue)

никогда не бросать

Когда второй ввод недоступен (или программист читает слишком мало документов и использует только первый), напишите такой код с регулярным выражением. Регулярные выражения - это круто, политкорректно и т. Д .:

Xxxxx.regex(".....pattern", src);
if (ImTotallySure)
{
  Example v = Example.Parse(src);
}

с этим кодом программисты не обходятся без исключений. НО ИМЕЕТ сопоставимую очень ВЫСОКУЮ стоимость регулярных выражений ВСЕГДА по сравнению с небольшой стоимостью исключения иногда.

Я почти всегда использую в таком контексте

try { parse } catch(ParsingException ) // concrete exception from javadoc
{
}

без анализа трассировки стека и т. д., я считаю, что после Ваших лекций довольно быстро.

Не бойтесь исключений

Отличный пост о производительности исключений:

https://shipilev.net/blog/2014/exceptional-performance/

Создание экземпляров и повторное использование существующих, с трассировкой стека и без и т. Д .:

Benchmark                            Mode   Samples         Mean   Mean error  Units

dynamicException                     avgt        25     1901.196       14.572  ns/op
dynamicException_NoStack             avgt        25       67.029        0.212  ns/op
dynamicException_NoStack_UsedData    avgt        25       68.952        0.441  ns/op
dynamicException_NoStack_UsedStack   avgt        25      137.329        1.039  ns/op
dynamicException_UsedData            avgt        25     1900.770        9.359  ns/op
dynamicException_UsedStack           avgt        25    20033.658      118.600  ns/op

plain                                avgt        25        1.259        0.002  ns/op
staticException                      avgt        25        1.510        0.001  ns/op
staticException_NoStack              avgt        25        1.514        0.003  ns/op
staticException_NoStack_UsedData     avgt        25        4.185        0.015  ns/op
staticException_NoStack_UsedStack    avgt        25       19.110        0.051  ns/op
staticException_UsedData             avgt        25        4.159        0.007  ns/op
staticException_UsedStack            avgt        25       25.144        0.186  ns/op

В зависимости от глубины трассировки стека:

Benchmark        Mode   Samples         Mean   Mean error  Units

exception_0000   avgt        25     1959.068       30.783  ns/op
exception_0001   avgt        25     1945.958       12.104  ns/op
exception_0002   avgt        25     2063.575       47.708  ns/op
exception_0004   avgt        25     2211.882       29.417  ns/op
exception_0008   avgt        25     2472.729       57.336  ns/op
exception_0016   avgt        25     2950.847       29.863  ns/op
exception_0032   avgt        25     4416.548       50.340  ns/op
exception_0064   avgt        25     6845.140       40.114  ns/op
exception_0128   avgt        25    11774.758       54.299  ns/op
exception_0256   avgt        25    21617.526      101.379  ns/op
exception_0512   avgt        25    42780.434      144.594  ns/op
exception_1024   avgt        25    82839.358      291.434  ns/op

Для других подробностей (включая ассемблер x64 от JIT) прочтите оригинальное сообщение в блоге.

Это означает, что Hibernate / Spring / etc-EE-shit работают медленно из-за исключений (xD).

Переписав поток управления приложением, избегая исключений (возвращая ошибку как return), улучшите производительность вашего приложения в 10-100 раз, в зависимости от того, как часто вы их бросаете))

Используя прилагаемый код на JDK 15, я получаю совершенно разные результаты для тестового примера @Mecki. Это в основном запускает код в 5 циклов, причем первый цикл немного короче, чтобы дать виртуальной машине время для разогрева.

Результаты:

Loop 1 10000 cycles
method1 took 1 ms, result was 2
method2 took 0 ms, result was 2
method3 took 22 ms, result was 2
method4 took 22 ms, result was 2
method5 took 24 ms, result was 2
Loop 2 10000000 cycles
method1 took 39 ms, result was 2
method2 took 39 ms, result was 2
method3 took 1558 ms, result was 2
method4 took 1640 ms, result was 2
method5 took 1717 ms, result was 2
Loop 3 10000000 cycles
method1 took 49 ms, result was 2
method2 took 48 ms, result was 2
method3 took 126 ms, result was 2
method4 took 88 ms, result was 2
method5 took 87 ms, result was 2
Loop 4 10000000 cycles
method1 took 34 ms, result was 2
method2 took 34 ms, result was 2
method3 took 33 ms, result was 2
method4 took 98 ms, result was 2
method5 took 58 ms, result was 2
Loop 5 10000000 cycles
method1 took 34 ms, result was 2
method2 took 33 ms, result was 2
method3 took 33 ms, result was 2
method4 took 48 ms, result was 2
method5 took 49 ms, result was 2

package hs.jfx.eventstream.api;

public class Snippet {
  int value;


  public int getValue() {
      return value;
  }

  public void reset() {
      value = 0;
  }

  // Calculates without exception
  public void method1(int i) {
      value = ((value + i) / i) << 1;
      // Will never be true
      if ((i & 0xFFFFFFF) == 1000000000) {
          System.out.println("You'll never see this!");
      }
  }

  // Could in theory throw one, but never will
  public void method2(int i) throws Exception {
      value = ((value + i) / i) << 1;
      // Will never be true
      if ((i & 0xFFFFFFF) == 1000000000) {
          throw new Exception();
      }
  }

  private static final NoStackTraceRuntimeException E = new NoStackTraceRuntimeException();

  // This one will regularly throw one
  public void method3(int i) throws NoStackTraceRuntimeException {
      value = ((value + i) / i) << 1;
      // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
      // an AND operation between two integers. The size of the number plays
      // no role. AND on 32 BIT always ANDs all 32 bits
      if ((i & 0x1) == 1) {
          throw E;
      }
  }

  // This one will regularly throw one
  public void method4(int i) throws NoStackTraceThrowable {
      value = ((value + i) / i) << 1;
      // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
      // an AND operation between two integers. The size of the number plays
      // no role. AND on 32 BIT always ANDs all 32 bits
      if ((i & 0x1) == 1) {
          throw new NoStackTraceThrowable();
      }
  }

  // This one will regularly throw one
  public void method5(int i) throws NoStackTraceRuntimeException {
      value = ((value + i) / i) << 1;
      // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
      // an AND operation between two integers. The size of the number plays
      // no role. AND on 32 BIT always ANDs all 32 bits
      if ((i & 0x1) == 1) {
          throw new NoStackTraceRuntimeException();
      }
  }

  public static void main(String[] args) {
    for(int k = 0; k < 5; k++) {
      int cycles = 10000000;
      if (k == 0) {
        cycles = 10000;
        try {
          Thread.sleep(500);
        }
        catch(InterruptedException e) {
          // TODO Auto-generated catch block
          e.printStackTrace();
        }
      }
      System.out.println("Loop " + (k + 1) + " " + cycles + " cycles");
      int i;
      long l;
      Snippet t = new Snippet();

      l = System.currentTimeMillis();
      t.reset();
      for (i = 1; i < cycles; i++) {
          t.method1(i);
      }
      l = System.currentTimeMillis() - l;
      System.out.println(
          "method1 took " + l + " ms, result was " + t.getValue()
      );

      l = System.currentTimeMillis();
      t.reset();
      for (i = 1; i < cycles; i++) {
          try {
              t.method2(i);
          } catch (Exception e) {
              System.out.println("You'll never see this!");
          }
      }
      l = System.currentTimeMillis() - l;
      System.out.println(
          "method2 took " + l + " ms, result was " + t.getValue()
      );

      l = System.currentTimeMillis();
      t.reset();
      for (i = 1; i < cycles; i++) {
          try {
              t.method3(i);
          } catch (NoStackTraceRuntimeException e) {
            // always comes here
          }
      }
      l = System.currentTimeMillis() - l;
      System.out.println(
          "method3 took " + l + " ms, result was " + t.getValue()
      );


      l = System.currentTimeMillis();
      t.reset();
      for (i = 1; i < cycles; i++) {
          try {
              t.method4(i);
          } catch (NoStackTraceThrowable e) {
            // always comes here
          }
      }
      l = System.currentTimeMillis() - l;
      System.out.println( "method4 took " + l + " ms, result was " + t.getValue() );


      l = System.currentTimeMillis();
      t.reset();
      for (i = 1; i < cycles; i++) {
          try {
              t.method5(i);
          } catch (RuntimeException e) {
            // always comes here
          }
      }
      l = System.currentTimeMillis() - l;
      System.out.println( "method5 took " + l + " ms, result was " + t.getValue() );
    }
  }

  public static class NoStackTraceRuntimeException extends RuntimeException {
    public NoStackTraceRuntimeException() {
        super("my special throwable", null, false, false);
    }
  }

  public static class NoStackTraceThrowable extends Throwable {
    public NoStackTraceThrowable() {
        super("my special throwable", null, false, false);
    }
  }
}