2013-02-10 15 views
6

na poziomie kodu Java bajtu, nie ma żadnych różnic pomiędzy prostą if-rachunku (Przykład 1) i Normal-rachunku (Przykład 2)prosty if porównaniu z normalną if

Przykład 1:

if (cond) statement; 

Przykład 2:

if (cond) { 
    statement; 
} 

tło pytaniem jest to, że widziałem w "wysokiej wydajności" klas jak java.awt.Rectangle i Point tylko wariant bez nawiasów klamrowych.

Czy są jakieś korzyści związane z prędkością, czy jest to tylko styl kodu?

+0

Dlaczego sam nie analizujesz? I zobacz, co otrzymasz. –

+0

Nie mam doświadczenia z kodem bajtu – raceworm

+0

dla downvoter: niektóre komentarze byłyby interesujące. – raceworm

Odpowiedz

10

Oprócz zdolności do konserwacji kodu, pod względem wydajności jest dokładnie taki sam. Nie uzyskasz przyspieszenia po usunięciu {}, ponieważ {} nie jest instrukcją przez niego.

Używam normalnie z {}, ponieważ sprawia, że ​​kod jest łatwy do odczytania (IMO) i mniej sprzyjający do popełniania błędów.

Ten przykład:

public void A(int i) { 
    if (i > 10) { 
     System.out.println("i"); 
     } 
    } 

    public void B(int i) { 
     if (i > 10) 
      System.out.println("i"); 
    } 

kod bajtowy generowane:

// Method descriptor #15 (I)V 
    // Stack: 2, Locals: 2 
    public void A(int i); 
    0 iload_1 [i] 
    1 bipush 10 
    3 if_icmple 14 
    6 getstatic java.lang.System.out : java.io.PrintStream [16] 
    9 ldc <String "i"> [22] 
    11 invokevirtual java.io.PrintStream.println(java.lang.String) : void [24] 
    14 return 
     Line numbers: 
     [pc: 0, line: 5] 
     [pc: 6, line: 6] 
     [pc: 14, line: 8] 
     Local variable table: 
     [pc: 0, pc: 15] local: this index: 0 type: program.TestClass 
     [pc: 0, pc: 15] local: i index: 1 type: int 
     Stack map table: number of frames 1 
     [pc: 14, same] 

    // Method descriptor #15 (I)V 
    // Stack: 2, Locals: 2 
    public void B(int i); 
    0 iload_1 [i] 
    1 bipush 10 
    3 if_icmple 14 
    6 getstatic java.lang.System.out : java.io.PrintStream [16] 
    9 ldc <String "i"> [22] 
    11 invokevirtual java.io.PrintStream.println(java.lang.String) : void [24] 
    14 return 
     Line numbers: 
     [pc: 0, line: 11] 
     [pc: 6, line: 12] 
     [pc: 14, line: 13] 
     Local variable table: 
     [pc: 0, pc: 15] local: this index: 0 type: program.TestClass 
     [pc: 0, pc: 15] local: i index: 1 type: int 
     Stack map table: number of frames 1 
     [pc: 14, same] 

Jak widać są takie same.

+0

i zawsze użyłem wariantu kręconego. ale suns java developper (s) nie, nawet android.graphics.Rect używa wariantu z pojedynczym stwierdzeniem. – raceworm

+1

@raceworm Jest to jednak konwencja kodowa, nie ma nic wspólnego z wydajnością, ponieważ nie ma różnicy w stosunku do wygenerowanego kodu. – nos

+0

doskonały. ......, myślałem również, że ta duża liczba if jest w tym szczególnym przypadku bardziej czytelna, z pojedynczą linią, jeśli – raceworm

4

Dwa są dokładnie takie same. Kompilacja Java stworzy ten sam kod.

Należy jednak pamiętać, że w przypadku nie-wspornika, nie będą mogli dodać wiele sub-wypowiedzi wewnątrz if-bloku drogę byłbyś w stanie w nawiasach przypadku

+0

Przetestowałeś to? –

+3

Nie powinno być żadnych różnic. Nie testowałem przy użyciu jakiejś kontroli kodu bajtowego, ale gdyby istniała różnica, te dwie instrukcje byłyby inaczej realizowane w API drzewa kompilatora (i nie ma między nimi żadnej różnicy) – malejpavouk

+0

, a nawet gdyby istniała jakaś różnica - Java ma właśnie na czas kompilator z HotSpot ... naprawdę wątpię, czy te optymalizacje micromicromicro mogą mieć mierzalny efekt – malejpavouk

1

dwa przykłady, które dałeś, robią dokładnie to samo. Pierwszym przykładem jest prosta instrukcja if-then, natomiast drugim przykładem jest normalna instrukcja if-then.

Czas potrzebny na wykonanie tych dwóch instrukcji jest taki sam, ponieważ nawiasy klamrowe nie są instrukcją, a zatem nie wpływają na szybkość. Nadal jednak używam zwykłego wyrażenia if, więc możesz mieć tyle instrukcji, ile chcesz w instrukcji if.

+0

Jestem zainteresowany ekstremalnym małym differenece, ponieważ potrzebuję go dla tysięcy rectangle.inside połączeń co sekundę na urządzeniu mobilnym – raceworm

+0

To jest w porządku, ale skupię się na innych, większych problemach związanych z chłodzeniem, zanim skupisz się na tak małych, – syb0rg

+0

, aby rozwiązać problem z powiększaniem pefrormancji za pomocą indeksu przestrzennego. – raceworm