Czy korzystanie z bloków try-catch jest drogie, nawet jeśli wyjątek nigdy nie jest zgłaszany?

Wiemy, że wychwytywanie wyjątków jest drogie. Ale czy korzystanie z bloku try-catch w Javie jest również kosztowne, nawet jeśli wyjątek nigdy nie jest zgłaszany?

Znalazłem pytanie / odpowiedź Przepełnienie stosu Dlaczego blokowanie prób jest drogie? , ale dotyczy .NET .

trynie ma prawie żadnych kosztów. Zamiast wykonywać konfigurację tryw czasie wykonywania, metadane kodu są ustrukturyzowane w czasie kompilacji, tak że kiedy zgłoszony jest wyjątek, wykonuje on stosunkowo kosztowną operację wchodzenia na stos i sprawdzania, czy tryistnieją jakieś bloki, które mogłyby to wychwycić wyjątek. Z punktu widzenia laika tryrównie dobrze może być bezpłatny. W rzeczywistości rzuca wyjątek, który cię kosztuje - ale dopóki nie wprowadzisz setek lub tysięcy wyjątków, nadal nie zauważysz kosztu.

trywiąże się z tym niewielkie koszty. Java nie może dokonać optymalizacji kodu w trybloku, który w przeciwnym razie by zrobił. Na przykład Java często zmienia kolejność instrukcji w metodzie, aby przyspieszyć jej działanie - ale Java musi także zagwarantować, że jeśli zostanie zgłoszony wyjątek, wykonanie metody jest obserwowane tak, jakby jej instrukcje zapisane w kodzie źródłowym były wykonywane w kolejności do jakiejś linii.

Ponieważ w trybloku może zostać zgłoszony wyjątek (w dowolnej linii w bloku try! Niektóre wyjątki są zgłaszane asynchronicznie, na przykład przez wywołanie stopwątku (który jest przestarzały), a nawet poza tym OutOfMemoryError może się zdarzyć prawie wszędzie), a jednak to może zostać przechwycony, a kod będzie kontynuowany po tej samej metodzie, trudniej jest uzasadnić optymalizacje, które można wprowadzić, więc jest mniej prawdopodobne, że tak się stanie. (Ktoś musiałby zaprogramować kompilator, aby to robił, uzasadniał i gwarantował poprawność, itp. Byłoby to wielkim problemem dla czegoś, co ma być „wyjątkowe”). Ale w praktyce nie zauważysz takich rzeczy.

Zmierzmy to, prawda?

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);
        }
    }
}

Na moim komputerze wyświetla się coś takiego:

try     0.598 ns
no try  0.601 ns

Przynajmniej w tym trywialnym przykładzie instrukcja try nie miała mierzalnego wpływu na wydajność. Możesz zmierzyć bardziej złożone.

Ogólnie rzecz biorąc, zalecam nie przejmować się kosztem wydajności konstrukcji językowych, dopóki w kodzie nie ma dowodów na rzeczywisty problem z wydajnością. Lub, jak ujął to Donald Knuth : „przedwczesna optymalizacja jest źródłem wszelkiego zła”.

try/ catchmoże mieć pewien wpływ na wydajność. Wynika to z faktu, że uniemożliwia ona JVM optymalizację. Joshua Bloch w „Skutecznej Javie” powiedział:

• Umieszczenie kodu w bloku try-catch hamuje pewne optymalizacje, które w przeciwnym razie mogłyby być wykonane przez współczesne implementacje JVM.

Tak, jak powiedzieli inni, tryblok hamuje niektóre optymalizacje {}otaczających go postaci. W szczególności optymalizator musi założyć, że w dowolnym punkcie bloku może wystąpić wyjątek, więc nie ma pewności, że instrukcje zostaną wykonane.

Na przykład:

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

Bez tego trywartość obliczona do przypisania xmoże zostać zapisana jako „wspólne podwyrażenie” i ponownie użyta do przypisania y. Ale z powodu trybraku pewności, że pierwsze wyrażenie zostało kiedykolwiek ocenione, więc wyrażenie musi zostać ponownie obliczone. Zwykle nie jest to wielka sprawa w kodzie „liniowym”, ale może być znacząca w pętli.

Należy jednak zauważyć, że dotyczy to TYLKO kodu JITCed. javac robi tylko optymistyczną optymalizację, a interpretator kodu bajtowego ma zerowy koszt wejścia / wyjścia z trybloku. (Nie ma generowanych kodów bajtowych do oznaczenia granic bloków).

A dla bestsss:

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

Wynik:

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

wyjście 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
}

Brak „GOTO”.

Aby zrozumieć, dlaczego nie można przeprowadzić optymalizacji, warto zrozumieć podstawowe mechanizmy. Najbardziej zwięzły przykład, jaki udało mi się znaleźć, został zaimplementowany w makrach C pod adresem : 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)

Kompilatory często mają trudności z określeniem, czy skok można zlokalizować na X, Y i Z, więc pomijają optymalizacje, których nie mogą zagwarantować bezpieczeństwa, ale sama implementacja jest raczej lekka.

Kolejny mikrobenchmark ( źródło ).

Stworzyłem test, w którym mierzę wersję kodu try-catch i no-try-catch na podstawie wartości procentowej wyjątku. 10% procent oznacza, że ​​10% przypadków testowych miało podział na zero przypadków. W jednej sytuacji jest obsługiwany przez blok try-catch, w drugiej przez operator warunkowy. Oto moja tabela wyników:

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

Procent | Wynik (try / if, ns)   
    0% | 88/90   
    1% | 89/87    
    10% | 86/97    
    90% | 85/83   

Co oznacza, że ​​nie ma znaczącej różnicy między tymi przypadkami.

Odkryłem, że łapanie NullPointException jest dość drogie. W przypadku operacji 1,2 tys. Czas wynosił 200 ms i 12 ms, kiedy wymieniałem go w ten sam sposób, if(object==null)co było dla mnie dość poprawą.