java-short,integer,long Leistung

Habe ich gelesen, dass die JVM speichert intern short, integer und long als 4 Byte. Ich lese aus einem Artikel aus dem Jahr 2000, also weiß ich nicht, wie wahr es ist jetzt.

Für die neueren JVMs ist, gibt es einen performance-Gewinn bei der Verwendung kurz über integer/long? Und Tat, dass ein Teil der Umsetzung hat sich verändert, seit 2000?

Dank

InformationsquelleAutor der Frage bob | 2010-03-04

  1. 12
    long  64 –9,223,372,036,854,775,808 to 9 ,223,372,036,854,775,807 
int   32 –2,147,483,648 to 2,147,483,647 
short 16 –32,768 to 32,767 
byte   8 –128 to 127

    Verwenden, was Sie brauchen, ich würde denken, shorts, die nur selten verwendet wegen der geringen Reichweite und ist es in big-endian-format.

    Alle performance-Gewinn wäre minimal, aber wie ich schon sagte, wenn Ihre Anwendung erfordert eine Reihe mehr, dass dann der eine kurze gehen mit int. Lange kann der Typ auch extrem groß für Sie; aber wieder, es hängt alles von Ihrer Anwendung.

    Sollten Sie verwenden Sie nur kurz, wenn Sie ein Anliegen haben, über Raum (Speicher), ansonsten mit int (in den meisten Fällen). Wenn Sie das erstellen von arrays und so versuchen Sie es durch die Deklaration von arrays vom Typ int und short. Kurz wird 1/2 der Raum im Gegensatz zu den int. Aber wenn Sie die tests ausführen, basierend auf der Geschwindigkeit /Leistung, die Sie sehen werden, wenig bis keinen Unterschied (wenn Sie den Umgang mit Arrays)darüber hinaus die einzige Sache, die Sie sparen Platz.

    Auch sein, dass ein commentor erwähnt long, weil eine long ist 64 bit. Sie werden nicht in der Lage zu speichern, die Größe von long in 4 bytes (beachten Sie die Reihe von langen).

    InformationsquelleAutor der Antwort JonH

  2. 15

    Integer-Typen gespeichert sind, in vielen bytes, abhängig von der genauen Art :

    • byte auf 8 bit
    • kurz auf 16 bit, signed
    • int auf 32 bit, signed
    • lange auf 64 bit, signed

    Sehen die Skillung hier.

    Als für die Leistung, es hängt davon ab, was man mit Ihnen tut.
    Zum Beispiel, wenn Sie die Zuweisung eines literalen Wert zu einem byte oder short sind, werden Sie hochskaliert auf int, weil literal-Werte als int-Werte durch default.

    byte b = 10;  //upscaled to int, because "10" is an int

    Das ist, warum Sie nicht tun können :

    byte b = 10;
b = b + 1;  //Error, right member converted to int, cannot be reassigned to byte without a cast.

    Also, wenn Sie planen, zu verwenden, bytes oder shorts zu führen einige Schleifen, Sie werden nicht alles gewinnen.

    for (byte b=0; b<10; b++) 
{ ... }

    Auf der anderen Seite, wenn Sie mit arrays von bytes oder shorts zu speichern einige Daten, werden Sie natürlich profitieren Sie von Ihrer Größe reduziert.

    byte[] bytes = new byte[1000];
int[] ints = new int[1000];  //4X the size

    So, meine Antwort ist : es hängt 🙂

    InformationsquelleAutor der Antwort Olivier Croisier

  3. 8

    Es ist eine Implementierung detail, aber es ist immer noch wahr, dass für die Leistung aus Gründen, die meisten JVMs verwenden eine vollständige Wort (oder mehr) für jede variable, da die CPUs auf den Speicher zugreifen, die in Wort-Einheiten. Wenn die JVM gespeichert, die Variablen, die in sub-Wort-Einheiten und Standorten, wäre es tatsächlich langsamer.

    Dies bedeutet, dass eine 32-bit-JVM verwenden 4 bytes für kurze (und sogar boolean) während einer 64-bit-JVM verwenden 8 Byte. Aber dasselbe gilt nicht für array-Elemente.

    InformationsquelleAutor der Antwort Michael Borgwardt

  4. 0

    Ich Stimme mit user2391480, Berechnungen mit shorts zu sein scheinen viel teurer. Hier ist ein Beispiel, wo auf meinem Rechner (Java7 64bit, Intel i7-3770, Windows 7) Betrieb mit shorts sind um ~50 mal langsamer als Integer und Long.

    public class ShortTest {

public static void main(String[] args){
    calculate();
    calculate();
}

public static void calculate(){
    int N = 100000000;

    long time1=System.currentTimeMillis();
    short s=0;
    for(int i = 0; i<N;i++) {
        s+=1;
        s-=1;
    }
    long time2=System.currentTimeMillis();
    System.out.println("Time elapsed for shorts: "+(time2-time1));


    long time3=System.currentTimeMillis();
    int in=0;
    for(int i = 0; i<N;i++) {
        in+=1;
        in-=1;
    }
    long time4=System.currentTimeMillis();
    System.out.println("Time elapsed for ints: "+(time4-time3));


    long time5=System.currentTimeMillis();
    long l=0;
    for(int i = 0; i<N;i++) {
        l+=1;
        l-=1;
    }
    long time6=System.currentTimeMillis();
    System.out.println("Time elapsed for longs: "+(time6-time5));


    System.out.println(s+in+l);
}

    }

    Ausgabe:

    Time elapsed for shorts: 113
Time elapsed for ints: 2
Time elapsed for longs: 2
0
Time elapsed for shorts: 119
Time elapsed for ints: 2
Time elapsed for longs: 2
0

    Hinweis: die Angabe "1" zu kurz sein (um zu vermeiden, casting jedes mal, wie vorgeschlagen, durch den Benutzer Robotnik als Quelle der Verzögerung) scheint nicht zu helfen, z.B.

        short s=0;
    short one = (short)1;
    for(int i = 0; i<N;i++) {
      s+=one;
      s-=one;
    }

    BEARBEITEN: geändert werden, wie pro Anforderung des Benutzers Hot Licks in den Kommentar, damit rufen Sie das calculate () - Methode mehr als einmal außerhalb der main-Methode.

    InformationsquelleAutor der Antwort Federico Giorgi

  5. 0

    Gibt es im Grunde keinen Unterschied. Man hat zu "verwirren" die JITC ein wenig, so dass es nicht erkannt wird, dass das Inkrement/Dekrement-Operationen sind selbst Lösch-und dass die Ergebnisse nicht verwendet werden. Tun Sie das und das drei Fällen kommen etwa gleich. (Eigentlich short scheint ein kleines bisschen schneller.)

    public class ShortTest {

    public static void main(String[] args){
        //Do the inner method 5 times to see how it changes as the JITC attempts to
        //do further optimizations.
        for (int i = 0; i < 5; i++) {
            calculate(i);
        }
    }

    public static void calculate(int passNum){

        System.out.println("Pass " + passNum);
        //Broke into two (nested) loop counters so the total number of iterations could
        //be large enough to be seen on the clock.  (Though this isn't as important when
        //the JITC over-optimizations are prevented.)
        int M = 100000;
        int N = 100000;
        java.util.Random r = new java.util.Random();
        short x = (short) r.nextInt(1);
        short y1 = (short) (x + 1);
        int y2 = x + 1;
        long y3 = x + 1;

        long time1=System.currentTimeMillis();
        short s=x;
        for (int j = 0; j<M;j++) {
            for(int i = 0; i<N;i++) {
                s+=y1;
                s-=1;
                if (s > 100) {
                    System.out.println("Shouldn't be here");
                }
            }
        }
        long time2=System.currentTimeMillis();
        System.out.println("Time elapsed for shorts: "+(time2-time1) + " (" + time1 + "," + time2 + ")");


        long time3=System.currentTimeMillis();
        int in=x;
        for (int j = 0; j<M;j++) {
            for(int i = 0; i<N;i++) {
                in+=y2;
                in-=1;
                if (in > 100) {
                    System.out.println("Shouldn't be here");
                }
            }
        }
        long time4=System.currentTimeMillis();
        System.out.println("Time elapsed for ints: "+(time4-time3) + " (" + time3 + "," + time4 + ")");


        long time5=System.currentTimeMillis();
        long l=x;
        for (int j = 0; j<M;j++) {
            for(int i = 0; i<N;i++) {
                l+=y3;
                l-=1;
                if (l > 100) {
                    System.out.println("Shouldn't be here");
                }
            }
        }
        long time6=System.currentTimeMillis();
        System.out.println("Time elapsed for longs: "+(time6-time5) + " (" + time5 + "," + time6 + ")");


        System.out.println(s+in+l);
    }
}

    Ergebnisse:

    C:\JavaTools>java ShortTest
Pass 0
Time elapsed for shorts: 59119 (1422405830404,1422405889523)
Time elapsed for ints: 45810 (1422405889524,1422405935334)
Time elapsed for longs: 47840 (1422405935335,1422405983175)
0
Pass 1
Time elapsed for shorts: 58258 (1422405983176,1422406041434)
Time elapsed for ints: 45607 (1422406041435,1422406087042)
Time elapsed for longs: 46635 (1422406087043,1422406133678)
0
Pass 2
Time elapsed for shorts: 31822 (1422406133679,1422406165501)
Time elapsed for ints: 39663 (1422406165502,1422406205165)
Time elapsed for longs: 37232 (1422406205165,1422406242397)
0
Pass 3
Time elapsed for shorts: 30392 (1422406242398,1422406272790)
Time elapsed for ints: 37949 (1422406272791,1422406310740)
Time elapsed for longs: 37634 (1422406310741,1422406348375)
0
Pass 4
Time elapsed for shorts: 31303 (1422406348376,1422406379679)
Time elapsed for ints: 36583 (1422406379680,1422406416263)
Time elapsed for longs: 38730 (1422406416264,1422406454994)
0

C:\JavaTools>java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

    InformationsquelleAutor der Antwort Hot Licks

  6. -2

    Berechnungen mit einer kurzen Art sind extrem teuer.

    Nehmen Sie die folgenden useless loop zum Beispiel:

    short t=0;
//int t=0;
//long t=0;
for(many many times...)
{
  t+=1;
  t-=1;
}

    Wenn es ist kurz, es dauert buchstäblich 1000 mal mehr als wenn es ein int oder ein long-Wert.

    Geprüft auf 64-bit-JVM-Versionen 6/7 auf Linux

    InformationsquelleAutor der Antwort user2391480

Schreibe einen Kommentar