Чи дорого використовувати пробні блоки, навіть якщо виняток ніколи не кидається?

Ми знаємо, що зловити винятки дорого. Але хіба також дорого використовувати блок Java-спроб-лову на Java, навіть якщо виняток ніколи не кидається?

Я знайшов питання / відповідь щодо переповнення стека Чому спробують блоки дорого? , але це для .NET .

tryмайже не має жодних витрат. Замість того, щоб виконувати роботу зі встановлення під час tryвиконання, метадані коду структуруються під час компіляції таким чином, що коли буде викинуто виняток, він виконує відносно дорогу операцію підйому стека та перегляду того, чи tryіснують блоки, які б зафіксували це виняток. З точки зору неспеціаліста, tryможе бути і вільним. Це насправді викидання виключення, яке коштує вам, але якщо ви не кинете сотні чи тисячі винятків, ви все одно не помітите вартість.

tryпов'язані з цим незначні витрати. Java не може виконати деякі оптимізації коду в tryблоці, які він інакше зробив би. Наприклад, Java часто переосмислює інструкції в методі, щоб змусити його працювати швидше - але Java також повинна гарантувати, що якщо буде викинуто виняток, виконання методу буде дотримуватися так, ніби його заяви, як написано у вихідному коді, виконані для того, щоб до якоїсь лінії.

Тому що в tryблоці може бути викинуто виняток (у будь-якому рядку блоку спробу! Деякі винятки викидаються асинхронно, наприклад, за допомогою виклику stopна Thread (який застаріло), і навіть крім цього OutOfMemoryError може траплятися майже де завгодно), і все ж це можна впіймати і код продовжувати виконувати згодом тим самим методом, складніше міркувати про оптимізації, які можна зробити, тому вони рідше трапляються. (Хтось повинен запрограмувати компілятор, щоб він їх робив, міркував і гарантував правильність і т. Д. Це було б великим болем за те, що означало бути "винятковим") Але знову ж таки, на практиці ви не помітите подібних речей.

Давайте це виміряємо, чи не так?

public abstract class Benchmark {

    final String name;

    public Benchmark(String name) {
        this.name = name;
    }

    abstract int run(int iterations) throws Throwable;

    private BigDecimal time() {
        try {
            int nextI = 1;
            int i;
            long duration;
            do {
                i = nextI;
                long start = System.nanoTime();
                run(i);
                duration = System.nanoTime() - start;
                nextI = (i << 1) | 1;
            } while (duration < 100000000 && nextI > 0);
            return new BigDecimal((duration) * 1000 / i).movePointLeft(3);
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }
    }

    @Override
    public String toString() {
        return name + "\t" + time() + " ns";
    }

    public static void main(String[] args) throws Exception {
        Benchmark[] benchmarks = {
            new Benchmark("try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        try {
                            x += i;
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                    }
                    return x;
                }
            }, new Benchmark("no try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        x += i;
                    }
                    return x;
                }
            }
        };
        for (Benchmark bm : benchmarks) {
            System.out.println(bm);
        }
    }
}

На моєму комп’ютері це друкує щось на кшталт:

try     0.598 ns
no try  0.601 ns

Принаймні, у цьому тривіальному прикладі, спробу твердження не мав помітного впливу на продуктивність. Сміливо вимірюйте більш складні.

Взагалі кажучи, я рекомендую не турбуватися про вартість продуктивності мовних конструкцій, поки у вас не з’являться докази фактичної проблеми з продуктивністю у вашому коді. Або як висловився Дональд Кнут : "передчасна оптимізація - корінь усього зла".

try/ catchможе мати певний вплив на продуктивність. Це тому, що заважає JVM робити деякі оптимізації. Джошуа Блох в "Ефективній Java" сказав наступне:

• Розміщення коду всередині блоку пробного захоплення гальмує певні оптимізації, які в іншому випадку можуть бути виконані сучасними програмами JVM.

Так, як говорили інші, tryблок гальмує деякі оптимізації для {}персонажів, що його оточують. Зокрема, оптимізатор повинен припускати, що виняток може статися в будь-якій точці блоку, тому немає впевненості, що оператори виконуються.

Наприклад:

    try {
        int x = a + b * c * d;
        other stuff;
    }
    catch (something) {
        ....
    }
    int y = a + b * c * d;
    use y somehow;

Без цього tryзначення, обчислене для присвоєння, можна xбуло б зберегти як "загальний піддекспресія" і повторно використовувати для призначення y. Але через tryвідсутність впевненості, що перший вираз колись оцінювали, тому вираз потрібно перерахувати. Зазвичай це не велика справа у прямолінійному коді, але може бути значним у циклі.

Слід зазначити, що це стосується ТОЛЬКО до коду JITCed. javac робить лише дивовижну кількість оптимізації, і для інтерпретатора байт-коду для введення / виходу з tryблоку немає нульової вартості . (Немає байткодових кодів, створених для позначення меж блоку.)

І для кращих результатів:

public class TryFinally {
    public static void main(String[] argv) throws Throwable {
        try {
            throw new Throwable();
        }
        finally {
            System.out.println("Finally!");
        }
    }
}

Вихід:

C:\JavaTools>java TryFinally
Finally!
Exception in thread "main" java.lang.Throwable
        at TryFinally.main(TryFinally.java:4)

javap вихід:

C:\JavaTools>javap -c TryFinally.class
Compiled from "TryFinally.java"
public class TryFinally {
  public TryFinally();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]) throws java.lang.Throwable;
    Code:
       0: new           #2                  // class java/lang/Throwable
       3: dup
       4: invokespecial #3                  // Method java/lang/Throwable."<init>":()V
       7: athrow
       8: astore_1
       9: getstatic     #4                  // Field java/lang/System.out:Ljava/io/PrintStream;
      12: ldc           #5                  // String Finally!
      14: invokevirtual #6                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      17: aload_1
      18: athrow
    Exception table:
       from    to  target type
           0     9     8   any
}

Ні «ГОТО».

Щоб зрозуміти, чому не можна виконати оптимізацію, корисно зрозуміти основні механізми. Найкращіший приклад, який я міг знайти, був реалізований у макросах C за адресою: http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

#include <stdio.h>
#include <setjmp.h>
#define TRY do{ jmp_buf ex_buf__; switch( setjmp(ex_buf__) ){ case 0: while(1){
#define CATCH(x) break; case x:
#define FINALLY break; } default:
#define ETRY } }while(0)
#define THROW(x) longjmp(ex_buf__, x)

У компіляторів часто виникають труднощі з визначенням того, чи можна стрибати локалізацію на X, Y і Z, тому вони пропускають оптимізацію, що не може гарантувати безпеку, але сама реалізація досить легка.

Ще один мікро-орієнтир ( джерело ).

Я створив тест, в якому вимірюю версію коду пробування і коду без спроби лову на основі відсотка винятку. 10% відсотків означає, що 10% тестових випадків мали поділ на нульові випадки. В одній ситуації він обробляється блоком "пробування", в іншій - умовним оператором. Ось моя таблиця результатів:

OS: Windows 8 6.2 x64
JVM: Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 23.25-b01

Відсоток | Результат (спробуйте / якщо, нс)   
    0% | 88/90   
    1% | 89/87    
    10% | 86/97    
    90% | 85/83   

Що говорить про те, що між жодним із цих випадків немає суттєвої різниці.

Я вважаю, що ловити NullPointException досить дорого. Для 1.2k операцій час становив 200 мс і 12 мс, коли я обробляв це так само, з чим if(object==null)було для мене досить вдосконаленим.