Geschwindigkeit von Java GUIs

[petetheat]

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]

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]

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]

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

 

[byte]

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]

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]

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]

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

 

[Marco13]

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

 

[AlArenal]

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:

Tu dich mal Flash Player installieren!

 

[Verjigorm]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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) {
    long time = System.currentTimeMillis();
    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);
    
    System.out.println(System.currentTimeMillis-time);

    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

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

liefert bei mir relativ konstant 3100 ms.

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

 

[Gast]

@Beni , da sinds dann 2 -3 ms

 

[Milo]

Hi,

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

Gruß Micha

 

[Guest]

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]

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

 

[Milo]

Hi,

passt jetzt. Geht nun deutlich schneller. Danke!

Gruß Micha

 

[Verjigorm]

da hammers doch
kaum macht man es richtig, gehts auch

 

[Milo]

Hallo,

kaum macht man es richtig

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

Micha

 

[byte]

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]

es war nicht falsch, aber es ging besser

 

[ARadauer]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

 

[Milo]

Hi,

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