Java: GUI = Performancekiller?

mj

Technische Administration, Dinosaurier, ,
Mitglied seit
17.10.2000
Beiträge
19.529
Renomée
272
Standort
Austin, TX
Mal eine kurze Frage: Den Primzahlalgorithmus der hier im Wettbewerb gefragt ist hab ich von einer Konsolen-Applikation umgesetzt in eine GUI-Applikation, mit schönem Fenster und einfacher Bedienung.
Allerdings ist jetzt die Performance mehr als unter aller Sau. Wo er vorher weniger als 7s gebraucht hat, braucht er jetzt für die gleiche Zahl über 15s. Wie gesagt, der Algorithmus ist gleich geblieben, lediglich eine GUI wurde dem ganzen verpasst.

Gibt es dafür eine logische Erklärung? Warum ist das Programm jetzt mit GUI plötzlich weniger als halb so schnell?
 
Moin,

die gui (wenn swing) wird gemalt (swing hat kaum peer objecte)...und das wahrscheinlich im selben Thread wie dein alg. rechnet.

Zum anderen wird durch die gui sowiso auch wieder ein wenig mehr speicher/rechenleistung benötigt.

mfg
 
Original geschrieben von D'Espice
Gibt es dafür eine logische Erklärung? Warum ist das Programm jetzt mit GUI plötzlich weniger als halb so schnell?
Poste doch einfach mal Deinen GUI-Quellcode.
 
Normalerweise hat man mit einer GUI nur Performanceprobleme, wenn man zu oft updatet. Wenn Du in jedem Schleifendurchlauf ein GUI-Update machst, ist das ein Problem. Wenn ich sowas in einem meiner Programme habe, dann mache ich mir einen Zähler und updatete das GUI dann z.B. nur in jedem tausendstem Durchlauf.

Könnte aber auch z.B. sein, dass bei Dir vieleicht ein Event-Handler zu oft aufgerufen wird - Da kann ich mich meinem Vorredner nur anschließen: Schwer zu sagen ohne es zu sehen.

m.f.g.
BoMbY

PS: Achja, das o.g. mit dem Thread könnte auch sein, versuch doch einfach mal Deine Berechnung in einen anderen Thread zu packen.
 
Die GUI wurde erstellt mit VEP/Eclipse und ich muss an dieser Stelle zugeben, dass ich bisher mit GUI und JAVA noch nicht viel Erfahrung habe. Bisher zwei Tage experimentieren und lesen, immerhin kapier ich jetzt die Grundprinzipien. Was ich noch lernen will ist wie man ein Fenster schließt und einen Wert zurückgibt und noch vieles mehr.

Der Quellcode für die GUI kann hier gefunden werden:
http://home.in.tum.de/~jungowsk/sw/java/PrimeApp
 
Hi,

also was fällt mir an Deinem Code auf:

1. Du benutzt die SWT, wenn Du das ganze mit der AWT machst, sollte es schneller sein.
2. Statt dem ActionListener kannst Du auch mal versuchen nur den mouseClicked Event abzufragen (Events -> Add Events -> Mouse - MouseAdapter -> mouseClicked)
3. Und der Übersichtlichkeit halber würde ich die Funktionalität aus der GUI-Klasse auslagern (halt irgendwie nach der Model-View-Controller Design Pattern).
4. Und wie oben schon erwähnt kann es dann immer noch zu Problemen kommen, weil die GUI und die Berechnung im gleichen Thread laufen.

m.f.g.
BoMbY
 
Welche GUI Frameworks gibt es für Java eigentlich? Die Standardanwendungen sehen ja eher karg aus und sind obendrein noch ewig langsam.

MfG
 
Möglicherweise kommt der Berechnung der EventDispatchThread in die Quere (oder die GarbageCollection, die ja bei ner GUI auch etwas mehr zu tun hat).

Was helfen könnte (!), wäre, die Berechnung in einen eigenen Thread auszulagern und diesem Thread eine hohe Priorität zu geben (Java API Doku zu Thread ). Während der Berechnung dürfte die GUI dann aber vermutlich recht zäh reagieren.

@Crashman: AWT, Swing und SWT sind die die ich kenne, aber es gibt vermutlich noch andere mit eher wenig Bedeutung in der Praxis.
 
Hmm... ich hab da ganze jetzt in einen eigenen Thread ausgelagert und gebracht hat es - exakt, garnichts. Immer noch doppelt so langsam wenn in GUI aufgerufen wie wenn in CLI aufgerufen *noahnung*
 
Zurück
Oben Unten