Java return Problem

In Java ist die Optimierung sowieso sinnlos, wenn die Java-VM der Meinung ist, sie weiß es besser als der Entwickler wird sie durch den Hotspot Compiler sowieso die sinnvollste Variante wählen.
 
1668mib schrieb:
Im Übrigen muss ich antred zustimmen.

Es ist auch nicht so, dass aus jeder Anwendung das letzte an Leistung rausgekitzelt werden muss - wenn dem so ist, dann sollte man kein Java nehmen...

Es gibt durchaus Fälle, bei denen Wartbarkeit wichtiger als Leistung ist.

Edit:
Und nochmal an die Optimierer:
"Because the case expressions in the following switch statement are not contiguous values, the
compiler will likely translate the code into a comparison chain instead of a jump table:"
Compiler werden auch optimiert vom Hersteller... ich würde echt mal Benchmarks machen, vermutlich wird kein Unterschied bei beiden Variaten in der JRE festgestellt...


Edit2:
Code:
public class Parser { 
     
    public static int parseIf(char c) { 
        if (c==' ') {
            return -1; 
        } else if (c=='+' || c=='-' || c=='/' || c=='*') { 
            return 0;
        } else if (c=='(') { 
            return 1;
        } else if (c==')') { 
            return 2;
        } else {
        	return 3;
        }
    }

    public static int parseSwitch(char c) {
    	switch (c) {
    	case ' ':
    		return -1;
    	case '+':
    	case '-':
    	case '/':
    	case '*':
            return 0;
    	case '(':
            return 1;
    	case ')':
            return 2;
        default:
        	return 3;
    	}
    }
    
    public static void main(final String[] args) {
    	String s = "+-/()((()))/**/*/-/-*-//*//*-/-*/*-/-*/*/*-/-*/++/+/+/+/+/+/+/+//**/+//+/+/*/*32/*+/+/*/+/+//*+/*/+*";
   
    	final long loops = 5000000;

    	// um Seiteneffekte zu vermeiden...
    	for (long i = 0; i < loops; i++) {
    		for (int j = 0; j < s.length(); j++) {
    			parseSwitch(s.charAt(j));
    			parseIf(s.charAt(j));
    		}
    	}

    	// Messen
    	long startI = System.currentTimeMillis();
    	for (long i = 0; i < loops; i++) {
    		for (int j = 0; j < s.length(); j++) {
    			parseIf(s.charAt(j));
    		}
    	}
    	long endI = System.currentTimeMillis();

    	long startS = System.currentTimeMillis();
    	for (long i = 0; i < loops; i++) {
    		for (int j = 0; j < s.length(); j++) {
    			parseSwitch(s.charAt(j));
    		}
    	}
    	long endS = System.currentTimeMillis();
       	
    	System.out.println("If: " + (endI - startI) + " Switch: " + (endS - startS));
    }
}

spuckt bei mir aus:
If: 4346 Switch: 4125

d.h. das sind 4,3 vs 4,1 Sekunden, und das bei 500.000.000 aufrufen an meinem Rechner... wenn der Leistungsunterschied hier nicht mal von essentieller Bedeutung ist...

Ok, dann scheint es in Java nicht der Fall zu sein das es was bringt.
In C/C++ bringt es aber durchaus etwas, den ansonsten würden nicht sowohl Intel als auch AMD dazu raten in bestimmten Fällen else-if statt switch zu benutzen!

@ice-breaker
So ein Unsinn, auch in Java sind Optimierungen Sinnvoll, den auch hier gilt nun mal das der Compiler das frisst was du im vorsetzt. So sollte man z.B. wissen wann man welche Variante der for-Schleife man nutzt und auch sonst gibt es viele Fälle in denen man optimieren sollte und nicht einfach irgend einen Code hinschreibt nach dem Motto "Hauptsache funktioniert".
 
Zuletzt bearbeitet:
Fonce schrieb:
Ok, dann scheint es in Java nicht der Fall zu sein das es was bringt.
In C/C++ bringt es aber durchaus etwas, den ansonsten würden nicht sowohl Intel als auch AMD dazu raten in bestimmten Fällen else-if statt switch zu benutzen!

Diese Art von Optimierung ist sehr 'low-level'. Sie kann dir natürlich unter Umständen was bringen, wenn du einen Anwendungsfall hast, bei dem du wirklich das letzte bißchen Leistung rauskitzeln mußt und schon alle anderen Optimierungsmöglichkeiten auf höheren Ebenen (effizientere Algorithmen / Datenstrukturen) erschöpft hast. Die Notwendigkeit, so weit zu gehen, dürfte allerdings eher selten bestehen.
 
Ja, das Motto "Hauptsache funktioniert" ist auch nicht sinnvoll, sagt ja keiner.

Das Ziel sollte aber erst mal verständlicher, wartbarer und auch vor allem funktionsfähiger Code sein. Wenn der von Anfang an schnell ist - gut. Wenn nicht, kann man noch versuchen, ihn schneller zu machen.

Und das mit dem "raten" von AMD und Intel - das sie unbestrittenerweise tun - ist so ne Sache. Da geht es um richtige Optimierung. Aber das ist was für Leute, die wirklich wissen was sie tun. Und die Leute stellen hier im Forum meist halt keine Fragen, zumindest nicht auf diesem Niveau. Vor allem wird dann zuerst am Algorithmus gefeilt (Edit @antred: musst du mir alles vorwegnehmen...) bevor der Code optimiert wird, denn dort zu optimieren bringt meist viel viel mehr...

Und Optimieren ist sinnvoll! Aber nur dort, wo es sich eben lohnt.
Auch unter C/C++ wirst du wegen dem Tauschen von Switch auf If keine Performancesprünge erzielen. Natürlich ist es dort in vielen Fällen schneller - vielleicht auch unter Java. Aber es ist alleine für sich halt ein Tropfen auf dem heißen Stein - in der Summe mit vielen anderen Optimierungen kann es vielleicht mal etwas bringen...

Und um nochmal auf die AMD-Doku zurückzukommen:
"This book is intended for compiler and assembler designers, as well as C, C++, and assemblylanguage
programmers writing performance-sensitive code sequences"
Ich sehe hier halt keinen der Punkte als erfüllt an...

Im Übrigen fällt mir gerade der Spruch ein "If it compiles, ship it" :-)
 
Fonce schrieb:
@ice-breaker
So ein Unsinn, auch in Java sind Optimierungen Sinnvoll, den auch hier gilt nun mal das der Compiler das frisst was du im vorsetzt. So sollte man z.B. wissen wann man welche Variante der for-Schleife man nutzt und auch sonst gibt es viele Fälle in denen man optimieren sollte und nicht einfach irgend einen Code hinschreibt nach dem Motto "Hauptsache funktioniert".

Was ist denn das für ein Schwachsinn?
Durch Flow-Analysen kann die Java VM theroetisch zwischen der switch-case-Variante und der if-Variante wechseln, wenn es Sinn machen würde, das ist aber eine Mikrooptimierung, irgendein dämlicher Algorithmus wird viel viel mehr Rechenzeit fressen, als diese absolute Low-Level-Optimierung, zumal diese auf die Java VM nicht zutreffen muss, da die Java VM eben wiederum eine eigene virtuelle Maschine definiert die nicht 1:1 auf eine Intel oder AMD CPU und deren Optimierung abbildbar sein muss.
Und das argumentiert der for-Schleife ist doch wohl lächerlich oder? Ausführungstechnisch sind alle Schleifen identisch, es gibt nämlich im Prozessor weder for oder while Schleifen, und die "enhanced for"-Schleife ist auch nur eine while-Schleife mit einigen angewendeten Compiler-Transformationen.


Ich sage nicht, dass optimieren sinnlos ist, aber etwas zu optimieren ohne gemessen zu haben, dass man es an der Stelle sollte, ist absoluter Schwachsinn, vor allem bei Mikro-Optimierungen.
 
Schon mal einen Benchmark erstellt welcher die verschiedenen Listentypen mit den verschiedenen For Schleifen durchläuft?
Wenn nicht, dann mach das mal...
 
Fonce schrieb:
Schon mal einen Benchmark erstellt welcher die verschiedenen Listentypen mit den verschiedenen For Schleifen durchläuft?
Wenn nicht, dann mach das mal...

Jetzt wechselst du das Thema. Du sprachst von Performanceunterschiede je nach unterschiedlichem Schleifenkonstrukt. Diese sind unerheblich für die Performance.

Nun lenkst du die Aufmerksamkeit auf die Effizienz von Listentypen, was gar nichts mit deiner ursprünglichen Behauptung zu tun hat.

Ansonsten wurde eigentlich alles schon gesagt:
- nur optimieren, wenn es auch ein Performanceproblem gibt
- Optimierungen führen i.d.R. zu unwartbareren Code
- Optimierungen sind potientiell fehleranfälliger, weil Sonderfälle oftmals nicht berücksichtigt werden
- Bevor man auf Codeebene optimiert sollte man den Algorithmus selbst optimieren, was viel mehr Beschleunigungspotenzial hat.
 
Oh gott.
Wenn ein Algorithmus mit else if 0,1 Sekunde schneller ist, als mit Switch ... Who cares?
Wenn die Berechnungszeit noch in einem vertretbaren Bereich, ist es sinnlos die Berechnung noch weiter zu optimieren.
Optimierungen nimmt man nur bei Zeitkritischen Anwendungen vor oder wenn wirklich ein akutes Performanceproblem vorliegt. Optimierungen kosten Geld. Geld, was man nicht für sinnlose 0,1 Sekunden verpulvern sollte.
Verschiedene Listentypen mit verschiedene For-Schleifen? Ich kenn nur eine For-Schleife.
Schonmal daran gedacht, dass es verschiedene Implementierungen der Listen gibt und diese somit unterschiedliche Laufzeiten haben?

Außerdem hat dies nichts mehr mit dem Thema zu tun.
 
Nochmal in einfach für den Threadersteller:

Es fehlt ein return außerhalb ("bzw. nach") deiner schleife.
 
Zurück
Oben