# Geschwindigkeit von Java GUIs



## petetheat (7. Jan 2008)

Hallo, ich hab mal eine allgemeine Frage zur Geschwindigkeit von Java Programmen und dabei insbesondere von GUIs. Ich hab einige kleinere und groessere GUIs mit Java schon gemacht und mir ist dabei aufgefallen, dass die alle doch recht langsam sind, wenn's z.B. darum geht neue Dialoge zu oeffnen oder einfach nur auf einen Button zu klicken.

Andererseits lese ich immer und ueberall, dass Java kaum merkbare Geschwindigkeitseinbussen gegenueber vergleichbaren C++ Programmen hat. Wie kann das denn sein? Liegt das vielleicht daran, dass ich die Sachen unter Windows ausfuehre?

Ich finde Java als Programmiersprache angenehmer als C++, aber es nervt schon, wenn ich ein GUI mit 4 Buttons habe und ich trotzdem noch warten muss, bis was passiert.


----------



## byte (7. Jan 2008)

Wenn Du merkbar warten musst, dann machst Du etwas falsch. Lässt Du Berechnungen im EDT durchführen?

Generell sind Swing GUIs schon ein wenig "träger" als native GUIs, aber Verzögerungsdifferenz liegt wohl eher im millisekunden Bereich. Also als "warten" würde ich das nicht bezeichnen.


----------



## petetheat (7. Jan 2008)

Also, z.B. bei einem Button oeffne ich einen JFileChooser, um eine Datei einzulesen. An anderer Stelle fuehre ich dann Berechnungen aus. Ist alles aber nicht wirklich besonders anspruchsvoll, aber die Verzoegerung ist eindeutig nicht mehr im millisekunden Bereich, sondern deutlich drueber.

Was meinst du mit EDT?


----------



## AlArenal (7. Jan 2008)

Mein Standard-Link zu diesem Thema: http://www.javalobby.org/eps/galbraith-swing-2/


----------



## byte (7. Jan 2008)

petetheat hat gesagt.:
			
		

> Was meinst du mit EDT?


EDT = Event Dispatch Thread, also der Hauptthread, der die GUI zeichnet. Rechenintensive Programmlogik sollte *immer* in einem eigenen Thread laufen, weil sonst der EDT blockiert und die GUI hakt oder sogar einfriert. Das liegt nicht an Java sondern in der Natur der Sache.
Ansonsten kann man dazu wenig sagen. Zeig halt mal Beispielcode, der bei Dir langsam ist.


----------



## Jango (7. Jan 2008)

AlArenal hat gesagt.:
			
		

> Mein Standard-Link zu diesem Thema: http://www.javalobby.org/eps/galbraith-swing-2/


Eine graue Seite? Oder ist das der beabsichtigte Kommentar dazu? :lol:


----------



## petetheat (7. Jan 2008)

Also, dann ist die Antwort ja, ich hab Berechnungen darin. Aber rechenintensiv weiss ich nicht, das ganze Programm ist eher billig und einfach gestrickt.


----------



## byte (7. Jan 2008)

Naja, wenn die Berechnung 200ms dauert, dann aktualisiert der EDT halt 200ms lang die GUI nicht.


----------



## Marco13 (7. Jan 2008)

"Billig und einfach" provoziert in gewissem Sinne, dass es NICHT effizient ist....  :lol: 
@Jango: Das ist eine Flash-Seite...


----------



## AlArenal (7. Jan 2008)

Jango hat gesagt.:
			
		

> AlArenal hat gesagt.:
> 
> 
> 
> ...



Tu dich mal Flash Player installieren!


----------



## Verjigorm (7. Jan 2008)

petetheat hat gesagt.:
			
		

> Also, dann ist die Antwort ja, ich hab Berechnungen darin. Aber rechenintensiv weiss ich nicht, das ganze Programm ist eher billig und einfach gestrickt.



vielleicht posteste mal nen bissl Code, dann können wir uns von überzeugen ob es einfach/billig ist ^^


----------



## Milo (7. Jan 2008)

Hi,

den JFileChooser möchte i9ch hier auch mal bestätigen. Mir ist auch aufgefallen, das es spürbar dauert, bis der zB Öffnen-Dialog erscheint und selbst das durchklicken im Verzeichnisbaum mitunter verzögert wird. Hier habe ich ja, bis auf das Öffnen selbst, kaum Einfluß auf den Code. 

Micha


----------



## Verjigorm (7. Jan 2008)

Also ich hab grad vor ner Woche 4 kleine Tools geschrieben, die auf dem JFilechooser basierten, da merk ich absolut keine Verzögerung beim öffnen oder durchklicken. Und ich hab nirgendwo irgendwelche Threads benutzt


----------



## tfa (7. Jan 2008)

JFileChooser ist vielleicht ein schlechter Maßstab. Kommt immer drauf an, wie viele Dateien/Verzeichnisse dargestellt werden. Und wenn unter Windows z.B. viele Netzlaufwerke angeschlossen sind und sämtliche CD-Laufwerke hochgefahren werden, dauert es nochmal länger.


----------



## petetheat (7. Jan 2008)

tfa, das ist aber kein Grund. Andere Programme brauchen dort ja auch nicht ewig.

Ich kann den Code leider nicht posten, ist Betriebsgeheimnis. Was ich aber sagen kann ist, dass ich drei ASCII Dateien einlese, deren Inhalt verwurschtel und eine CSV Datei erzeuge.

Mit billig und einfach meinte ich auch nicht, dass der Code schlecht oder ineffizient programmiert ist, sondern, dass nicht wirklich viel Kunst dahinter steckt. Ich lese alle Dateien zeilenweise ein, suche bestimmte Werte darin und schreibe alles zusammen in eine CSV. Ich weiss nicht, was ich da effizienter programmieren koennte, um Geschwindigkeitsvorteile zu erzielen.


----------



## Verjigorm (7. Jan 2008)

tfa hat gesagt.:
			
		

> JFileChooser ist vielleicht ein schlechter Maßstab. Kommt immer drauf an, wie viele Dateien/Verzeichnisse dargestellt werden. Und wenn unter Windows z.B. viele Netzlaufwerke angeschlossen sind und sämtliche CD-Laufwerke hochgefahren werden, dauert es nochmal länger.



also unser Arbeitsplatz hat 18 Laufwerke und atm 2,2TB und ich starte den JFileChooser auf dem Netzwerklaufwerk.
Mit einigen Hundert Textfiles (bis zu 500mb pro File) im Ordner und der brauch keine 200ms um alles zu öffnen etc.


@petetheat:
wo liegt denn nun eigentlich das Problem?
Beim verarbeiten der ASCII-Tabellen hängt die GUI? -> Threads!
Oder was?


----------



## byte (7. Jan 2008)

petetheat hat gesagt.:
			
		

> tfa, das ist aber kein Grund. Andere Programme brauchen dort ja auch nicht ewig.


Nö, aber ewig braucht der Java Filechooser auch nicht.



> Ich kann den Code leider nicht posten, ist Betriebsgeheimnis. Was ich aber sagen kann ist, dass ich drei ASCII Dateien einlese, deren Inhalt verwurschtel und eine CSV Datei erzeuge.


Miss halt die Zeit, dann weisst Du wie lang das dauert. Bei solchen IO-Operationen kannste aber fast schon pauschal sagen, dass das nicht in den EDT gehört.



> Mit billig und einfach meinte ich auch nicht, dass der Code schlecht oder ineffizient programmiert ist, sondern, dass nicht wirklich viel Kunst dahinter steckt. Ich lese alle Dateien zeilenweise ein, suche bestimmte Werte darin und schreibe alles zusammen in eine CSV. Ich weiss nicht, was ich da effizienter programmieren koennte, um Geschwindigkeitsvorteile zu erzielen.


Es ist völlig irrelevant, ob der Code nun kunstvoll ist oder nicht. Es geht einzig um die Resourcen, die dem EDT zum aktualisieren der GUI verloren gehen.

Naja, eine Antwort auf Deine Frage hast Du nun ja. Du kannst also entweder weiter drum herum reden und Java für langsam halten. Oder Du kannst einfach richtig programmieren.


----------



## Milo (7. Jan 2008)

Hi,

ich kann langsam bis 3 zählen, bis sicher der Dialog öffnet. Die Methode sieht hierzu wie folgt aus:


```
private File showOpenDialogAndGetSelectedFile(String title, String label, String ext) {
    JFileChooser fc = new JFileChooser();
    final String extension = (ext==null||ext.length()==0)?".txt":ext;
    fc.setFileFilter( new FileFilter() {
      @Override
      public boolean accept( File f ) {
        return f.isDirectory() || f.getName().toLowerCase().endsWith( extension );
      }

      @Override
      public String getDescription() {
        return "Datei (* " + extension + ")";
      }
    });
    
    File selectedFile = null;

    if (this.userPath != null){
      fc.setCurrentDirectory( this.userPath );
    }

    fc.setDialogType(JFileChooser.OPEN_DIALOG);
    fc.setDialogTitle(title);
    fc.setApproveButtonText(label);

    if (fc.showOpenDialog(null) == JFileChooser.APPROVE_OPTION) {
      return fc.getSelectedFile();
    }
    return null;
  }
```

Ist der so schlecht???

PC: IntelDuo; 1GB RAM; VISTA; Java 1.6

Micha


----------



## L-ectron-X (7. Jan 2008)

Milo hat gesagt.:
			
		

> den JFileChooser möchte i9ch hier auch mal bestätigen. Mir ist auch aufgefallen, das es spürbar dauert, bis der zB Öffnen-Dialog erscheint und selbst das durchklicken im Verzeichnisbaum mitunter verzögert wird.


Hier kommt es darauf an, ob es bereits eine anzeigbare Instanz im Speicher gibt, oder ob du den JFileChooser erst vor dem Öffnen instanziierst.


----------



## Beni (7. Jan 2008)

Dann mach mal einen Test, wie es ohne das "new JFileChooser()" aussieht:

```
private JFileChooser fc = new JFileChooser();

  private File showOpenDialogAndGetSelectedFile(String title, String label, String ext) {
    final String extension = (ext==null||ext.length()==0)?".txt":ext;
    fc.setFileFilter( new FileFilter() {
      @Override
      public boolean accept( File f ) {
        return f.isDirectory() || f.getName().toLowerCase().endsWith( extension );
      }

      @Override
      public String getDescription() {
        return "Datei (* " + extension + ")";
      }
    });
   
    File selectedFile = null;

    if (this.userPath != null){
      fc.setCurrentDirectory( this.userPath );
    }

    fc.setDialogType(JFileChooser.OPEN_DIALOG);
    fc.setDialogTitle(title);
    fc.setApproveButtonText(label);

    if (fc.showOpenDialog(null) == JFileChooser.APPROVE_OPTION) {
      return fc.getSelectedFile();
    }
    return null;
  }
```


----------



## Guest (7. Jan 2008)

Milo hat gesagt.:
			
		

> Hi,
> 
> ich kann langsam bis 3 zählen, bis sicher der Dialog öffnet. Die Methode sieht hierzu wie folgt aus:
> 
> ...



showOpenDialogAndGetSelectedFile("a", "b", null);

liefert bei mir relativ konstant 3100 ms. 

Turion 64 x2, 2gb ram, vista, java 1.6


----------



## Gast (7. Jan 2008)

@Beni , da sinds dann 2 -3 ms


----------



## Milo (7. Jan 2008)

Hi,

Du meinst ich soll ihn als Klassenvariable deklarieren und nicht als Variable der Methode?

Gruß Micha


----------



## Guest (7. Jan 2008)

Milo hat gesagt.:
			
		

> Hi,
> 
> Du meinst ich soll ihn als Klassenvariable deklarieren und nicht als Variable der Methode?
> 
> Gruß Micha



Im prinzip schon. Andererseits verschiebt es das Problem unter umständen nur, da das instanziieren des Filechoosers trotzdem seine Zeit dauert. Wenn man das instanziieren zu einer Zeit ausführt an dem die VM sowieso nichts macht, sollte man diese Zeit nutzen.
Bei mehrmaligem aufruf der Methode wird der Filechooser nur einmal instanziiert werden. Es werden ja lediglich ein paar properties gesetzt und der Filechooser angezeigt, was kaum Zeit beansprucht


----------



## L-ectron-X (7. Jan 2008)

Als Instanzvariable, ja. Und die Instanz vom JFileChooser bereits im Konstruktor dieser Klasse erzeugen.


----------



## Milo (7. Jan 2008)

Hi,

passt jetzt. Geht nun deutlich schneller. Danke!

Gruß Micha


----------



## Verjigorm (7. Jan 2008)

da hammers doch
kaum macht man es richtig, gehts auch


----------



## Milo (8. Jan 2008)

Hallo,



			
				Verjigorm hat gesagt.:
			
		

> kaum macht man es richtig



das Impliziert jedoch, ich hätte einen Fehler im Code gehabt. ;-)

Micha


----------



## byte (8. Jan 2008)

Hinsichtlich des von Dir angesprochenen Performance-Problems war das ja auch so. Man merkt daran mal wieder, dass es sinnvoll ist, den Fehler zunächst bei sich selbst zu suchen, anstatt ihn der Programmiersprache unterzujubeln.


----------



## Verjigorm (8. Jan 2008)

es war nicht falsch, aber es ging besser


----------



## ARadauer (8. Jan 2008)

Irgendwie eine gereizte Stimmung hier?

Also generell zur Lösung kann man sagen: es ist besser einen Dialog zu Beginn zu instanzieren und nicht erst wenn er benötigt wird, damti der Benutzer nicht warten muss.

@performance: Ich muss dem threadsteller aber auch zustimmen, die instanzieren von zb JFileChosser braucht seine zeit

aber da hat ja beni die lösung geliefert


----------



## Verjigorm (8. Jan 2008)

ARadauer hat gesagt.:
			
		

> Irgendwie eine gereizte Stimmung hier?



ähm hä???
hier ist alles ganz lieb und freundlich, hast du Halluzinationen? 
Bisher nicht ein böses Wort gefallen ...

smilies  sind doch alle lieb gemeint


----------



## Niki (8. Jan 2008)

ARadauer hat gesagt.:
			
		

> Also generell zur Lösung kann man sagen: es ist besser einen Dialog zu Beginn zu instanzieren und nicht erst wenn er benötigt wird, damti der Benutzer nicht warten muss.



Das heißt du erstellst die Dialoge am Anfang der Applikation und machst sie dann nur unsichtbar, ohne dispose? Damit du sie wieder schneller anzeigen kannst?


----------



## petetheat (8. Jan 2008)

Ich habe nie gesagt, dass der Fehler bei der Programmiersprache liegt. Ich muss auch dazu sagen, dass ich kein Programmierer, sondern Ingenieur bin, und meine Programme daher meistens von der Programmierung her effektiver sein koennten, ich weiss das selbst.

Nur ist es halt so, dass wenn jemand wie ich rein intiutiv programmiert, C Programme wirklich erstmal schneller ausgefuehrt werden als Java Programme. 
Ich will jetzt keinen Streit vom Zaun brechen, ich finde Java bei weitem angenehmer als C, aber ist es nicht ein Nachteil der Sprache, wenn man als Anfaenger schneller so abgeschreckt wird?


----------



## byte (8. Jan 2008)

Die Sprache kann dem Entwickler nicht alles abnehmen. Es gehört auch immer ein bißchen Erfahrung dazu, um effektive Programme zu schreiben. Java ist zwar sehr entwicklerfreundlich, mehr als manch andere Sprache, trotzdem muss man es erstmal lernen.
Es steht Dir natürlich frei, statt Java Swing eine native GUI-Variante zu wählen wie z.B. SWT. Da kannst Du dann die nativen GUI-Resourcen des OS verwenden. Die Plattformunabhängigkeit ist damit natürlich auch dahin.

So ganz kann ich Dich aber auch nicht verstehen. Du sagst, Du wirst als Anfänger von Java abgeschreckt, weil der JFileChooser 3 Sekunden braucht, bis er sich öffnet. Als ich damals vor solchen Anfängerproblemen stand, habe ich den Fehler erstmal bei mir gesucht und geguckt, ob ich eine Lösung für das Problem finden kann. Das hat auch in 99% der Fälle geklappt. Das ist der natürliche Lernprozess. Wenn man stattdessen sagt "geht nicht, blöde Programmiersprache, macht keinen Spaß", dann wird mans auch bei anderen Dingen im Leben nicht weit bringen. Denn auf Probleme stößt man überall.


----------



## petetheat (8. Jan 2008)

Das hab ich auch nie in Frage gestellt, wie gesagt, ich weiss ich koennte effektiver programmieren. Und ich bin ja auch echt dankbar fuer Foren wie dieses, wo ich solche Sachen posten und davon lernen kann.

Aber haengt es nicht vielleicht eben damit zusammen, dass Java als so langsam verschrien ist, dass man wirklich erst Erfahrung sammeln muss, um die Geschwindigkeit zu erreichen, die bei anderen Sprachen intuitiver vorhanden ist?


----------



## tfa (8. Jan 2008)

petetheat hat gesagt.:
			
		

> Aber haengt es nicht vielleicht eben damit zusammen, dass Java als so langsam verschrien ist, dass man wirklich erst Erfahrung sammeln muss, um die Geschwindigkeit zu erreichen, die bei anderen Sprachen intuitiver vorhanden ist?



Das hängt eher damit zusammen, dass Java früher (vor so 10-12 Jahren) wirklich langsam war.


----------



## Marco13 (8. Jan 2008)

IMHO hängt es auch damit zusammen, dass Java sehr einsteigerfreundlich ist. Wenn der Threadersteller das ganze mit C++ und WxWidgets machen müßte, würde er nicht fragen "Wieso dauert es so lange, wenn ich 'fileChooser=new FileChooser()' mache?", sondern er würde fragen: "Hilfe, wie kann ich denn ein ganz normales Fenster aufmachen?"....


----------



## petetheat (8. Jan 2008)

Ja, aber wenn sich jemand ransetzt und Java lernt, dabei immer noch im Hinterkopf hat, Java ist ja eh langsam. Dann trifft er auf das Problem, das ich mit dem JFileChooser hatte (was ich uebrigens aus einem Beispiel irgendwo her uebernommen habe, wo genau weiss ich leider nicht mehr). Da er davon ausgeht, dass das Beispiel so ok ist und es funktioniert ja auch, ist erstmal die Erkenntnis da "ah ja, java ist echt lahm"

Ich weiss, das ist der "wenn der Bauer nicht schwimmen kann, liegt's an der Badehose"-Effekt, aber ich finde, dies ist eindeutig ein Nachteil der Sprache.


----------



## byte (8. Jan 2008)

Du wirst zu jeder Programmiersprache ineffektive Codebeispiele im Netz finden. Das betrifft doch längst nicht nur Java.
Der JFileChooser ist halt ein extremes Beispiel für den Tradeoff, den ein solches plattformunabhängiges GUI-Framework mit sich bringt. Manche Sachen sind halt langsamer als nativer Code, dafür läufts auf (fast) allen Plattformen.

Es ist halt nun mal ein Unterschied, ob das Framework einfach nur native Funktionalität des OS aufruft oder eine eigene Implementierung bereit stellt, die völlig unabhängig vom OS ist. Bei den meisten Swing Komponenten wirst Du aber kaum einen Unterschied feststellen. Im übrigen müssen native Komponenten auch erstmal geladen werden, nur das passiert halt schon bevor das Programm gestartet wird (z.B. beim Start des OS).


----------



## petetheat (8. Jan 2008)

Ich sehe schon, diese Diskussion fuehrt zu nichts mehr 

Ich hab meine Loesung mit dem JFileChooser genauso wie ich meine Meinung habe und ihr habt eure, also lasst uns doch alle gluecklich sein.


----------



## AlArenal (8. Jan 2008)

petetheat hat gesagt.:
			
		

> Ich hab meine Loesung mit dem JFileChooser genauso wie ich meine Meinung habe und ihr habt eure, also lasst uns doch alle gluecklich sein.



Seit wann ist ein deterministisches System eine Sache von "Meinung"? Mit der Einstellung wirst du weit kommen...


----------



## petetheat (8. Jan 2008)

AlArenal hat gesagt.:
			
		

> Seit wann ist ein deterministisches System eine Sache von "Meinung"? Mit der Einstellung wirst du weit kommen...



Ich dachte, das Thema waere beendet. Aber natuerlich kann man eine Meinung ueber Vor- und Nachteile insbesondere bzgl. der Erlernbarkeit einer Sprache haben, ich verstehe nicht, wo das Problem liegt?


----------



## AlArenal (8. Jan 2008)

Ich bezog deine Aussage auf das konkrete Problem und darauf, dass du dir von erfahreneren Codern nichts sagen lassen wolltest.

Wenn "Erlernbarkeit" weit gefasst wird und man die Weigerung sich etwas sagen zu lassen darunter fallen lässt, magst du Recht haben.


----------



## petetheat (8. Jan 2008)

Wo hab ich mir denn nichts sagen lassen wollen? Ich hab doch gesagt, dass die Aenderung mit dem JFileChooser was gebracht hat.


----------



## Milo (8. Jan 2008)

Hi,



			
				Verjigorm hat gesagt.:
			
		

> es war nicht falsch, aber es ging besser



sehr diplomatisch formuliert ;-) Das die Optimierung geglückt ist, hatte ich ja bereits verkündet!


Gruß Micha


----------

