Code-Optimierungen



  • Hallo,
    ich will einen Code schneller machen.

    Den Trick statt ...

    [java]
    String tmpString = new String();
    for(int i = 0; i < 10000; i++){
    tmpString += ".";
    }[/code]

    ... es mit einem Stringbuffer zu machen ...

    [java]
    StringBuffer tmpStringBuffer = new StringBuffer();
    for(int i = 0; i < 10000; i++){
    tmpStringBuffer.append(".");
    }[/code]

    ... kenne ich schon.

    Gibt es da noch ähnliches, wie z. B. statt ...

    [java]
    float[] tmpfloatArray = new float[3];[/code]

    ... besser ...

    [java]
    float tmpfloat_1, tmpfloat_2, tmpfloat_3;[/code]

    ... oder so etwas?

    Wahrscheinlich ist ein zweidimensionales 4x4-Array auch langsamer als ein eindimensionales 1x16 Array, oder?



  • Bringt es was, wenn ich statt ...

    [java]
    for(int i = 0; i < 50; i++){
    // Irgendwas machen
    }[/code]

    ... ein byte nehme, wenn ich weiss, dass die Schleife nur bis z. B. 50 geht?

    [java]
    for(byte i = 0; i < 50; i++){
    // Irgendwas machen
    }[/code]



  • Speichertechnisch ja denn byte belegt 8 Bit wohingegen der normale int 32 Bit benötigt. Übrigens gibts vor int und nach byte noch short 🙂

    byte < short < int < long

    Generell kann ich dir aber die folgende Seite als Lektüre empfehlen. Java Optimization

    [ Dieser Beitrag wurde am 04.07.2002 um 10:38 Uhr von CengizS editiert. ]



  • Ich denke, Code-Optimierungen bringen nur an den Stellen etwas, die oft durchlaufen werden. Es dürfte etwas bringen, wenn du den Code, den du aus solchen oft durchlaufenen Stellen auslagern kannst, auslagerst.

    Wenn du oft die Größe eines Arrays verändern mußt, dann könnte es etwas bringen, statt eines Arrays eine dynamische Datenstruktur zu nehmen (Also z.B. einen Vektor, oder eine LinkedList). Was jeweils am Besten ist, hängt von den Operationen ab, die du auf der Datenstruktur durchführst : Wenn du die Datenstruktur oft erweitern möchtest, dann ist eine Liste besser, wenn du oft auf bestimmte Elemente der Datenstruktur zugreifen möchtest, dann ist ein Vektor besser.

    [ Dieser Beitrag wurde am 10.03.2003 um 21:32 Uhr von Gregor editiert. ]



  • Achtung bei Ersetzung von int gegen byte gibt es einen Geschwindigkeitsnachteil. Integer ist je nach System/Prozessor 32 Bit. Also genau die Wortbreite des Prozessors. Byte ist kleiner und muss deshalb runtergebrochen werden. Das führt dann zu Geschwindigkeitsverlusten.
    Erwähnen könnte man noch gepufferte Streams für IO.
    Ein paar weitere Anregungen zum Thema Performance gibt es auch in der offline-Version von www.javabuch.de .

    gruß dirk



  • Ein int umfaßt in Java nach Sprachspezifikation 32 Bit. Das ist hier unabhängig vom Prozessor. In C oder C++ ist das allerdings anders.

    Ich verstehe nicht ganz, warum ein Prozessor ein Byte langsamer verarbeiten sollte, als ein int. Ich kann mir aber vorstellen, dass es da überhaupt keinen Geschwindigkeitsunterschied gibt.

    ...gepufferte Streams sind gut! Den Geschwindigkeitsunterschied kann man gut sehen, wenn man eine längere Textdatei oder ein Bild einmal mit und einmal ohne gepufferte Streams ladet. ...da muss man die Zeit nichtmal mit dem Computer messen, da man das auch so deutlich merkt.



  • Stimmt, war immer gleich.
    mmh, vielleicht vermenge ich da gerade c/c++ und java.
    Ich werde das nochmal nachlesen. Die Idee ist jedenfalls, das ein 32bit Prozessor intern mit 32bit Registern arbeitet. Die Grenzen sind da also ganz natürlich aus dem Aufbau der Register gegeben. Wenn man nun ein Byte (mit 8 bit) hat, müssten die Grenzen künstlich überwacht werden. -> und das würde dann zu einem geschwindigkeitsverlust führen.
    Der Unterschied sollte natürlich nicht besonders hoch sein. Mir ist das nur mal irgendwo hängengeblieben, weil ich früher relativ oft byte anstelle von int verwendet habe... und danach nicht mehr. 🙂


Anmelden zum Antworten