[AWT]: Was macht EventQueue.getNextEvent()

[Lin728]

Hallo!

Ich schreibe gerade ein ziemelich komplexes AWT-Widget und habe das Problem, dass die Methode getNextEvent 40% der CPU-Zeit des Programms in Anspruch nimmt.

De ganze Arbeit wird in einem actionPerformed() in einem MouseListener gemacht.
Man sieht das auch sehr gut im Profilier, dass in dispatchEvent 60% CPU-Zeit benötigt, weil ja da die ganze Arbeit gemacht wird, aber für was bitte brauch getNextEvent() 40% der Gesamtzeit?

Hab natürlich ein Bildchen meines Profiliers angehängt, ignoriert das rote einfach....

Mfg

[bischi]

Soweit ich weiss, nimmt dieses die nächste Meldung aus der Nachrichtenschleife und handelt diese danach ( wie weit weiss ich nicht ) auch ab. Bei Mausnachrichten dürften dies wohl relativ viele sein! (Mouse moved,...)

MfG Bischi

[Lin728]

Grüssi!

Ja genau, das hab ich eben auch in den Apidocs gelsenen, drum hats mich gewundert, warum das so enorm viel CPU-Zeit braucht.

Ich habe nur einen ActionEvent auf EINEN Button, alle anderen Listings habe ich entfernt, weil ich gleich gedacht habe, dass es an den ganzen listenern liegen könnte.
Aber ein ActionEvent sollte keine 40% erzeugen.

Soweit ich weiß wird die ganze Arbeit dispatchEvent() erledigt, getNextEvent hat soweit ich weiß nix mit meinem Code zu tun, oder?

[bischi]

Ich nehme mal an, das nimmt jeweils die nächste Nachricht, egal ob es eine nächste gibt (versucht einfach die nächste Nachricht zu kriegen).

Somit läuft dies wohl die ganze Zeit und beansprucht so den Prozessor!

MfG Bischi

PS: Habs mir nochmals überlegt, nachdem ich das Bild nochmals angeschaut habe:

Diese Klasse bearbeitet ALLE Nachrichten, die Windows/Linux/... an Java liefert (Maus, Tastatur, ...). Somit ist diese Auslastung doch verständlich.
Wenn du einen MouseListener machst, gibtst du nur bekannt, dass du Mausnachrichten weiterverfolgen willst. Die Nachrichten bekommt Java auf jeden Fall!

[Lin728]

Grüssi!

Und warum haben dann andere Java-Programm nicht 40% auslastung.
Hier handelt es sich definitiv um ein Problem in meinem Programm, nicht um etwas, was sowieso generell bei jedem Java-Programm ist.
Bei jedit steht getNextEvent gar nicht im Profilier als Hotstop drinnen -> weniger als 0.2% CPU-Zeit.

lg

[peschmae]

also 40% der CPU-Zeit oder 40% der CPU-Zeit des Java-Programms?

Ersteres fänd ich äusserst bedenklich. (Dos programme machen das mit 100%, aber sonst :confused:).

Zweiteres könnte ich nicht beurteilen.

MfG Peschmä

[bischi]

Falls 40% des Programms:

Da dein Programm sonst wohl nichts macht, sind 40% doch noch im Rahmen des Möglichen. Jedit macht wohl sonst noch so einiges, das den Prozessor belastet. Daher nimmt dieser Prozess dann wohl nur wenige Prozent in Anspruch. Abgesehen davon: Ist Jedit nicht Swing?

Es wäre interessant, absolute Werte zu vergleichen - schreib mal ein ganz simples HelloWorld Programm und vergleich die absoluten Werte. Weiss nicht, wie dein Programm misst, doch je nach dem kommt es auch darauf an, wie lange das Programm zum messen läuft - ausser Nachrichten empfangen, muss es sonst ja nichts machen.


Ich selbst verwende getNextEvent ÜBERHAUPT nicht, das ist alles AWT-intern

Genau das meine ich ja: Diese Funktion empfängt Java-intern alle Nachrichten, die irgendwer sendet. Dies ganz unabhängig, ob du sie bearbeitest (verkleinern - vergrössern Knopf funktioniert ja auch, somit muss Java diese Nachricht unter vielen empfangen und bearbeiten).

Zitat aus der Doku:

Removes an event from the EventQueue and returns it. This method will block until an event has been posted by another thread.

Könnte mir das gesamte auch nicht anders erklären,
mfG Bischi

[Lin728]

Da dein Programm sonst wohl nichts macht, sind 40% doch noch im Rahmen des Möglichen. Jedit macht wohl sonst noch so einiges, das den Prozessor belastet. Daher nimmt dieser Prozess dann wohl nur wenige Prozent in Anspruch. Abgesehen davon: Ist Jedit nicht Swing?

Es wäre interessant, absolute Werte zu vergleichen - schreib mal ein ganz simples HelloWorld Programm und vergleich die absoluten Werte. Weiss nicht, wie dein Programm misst, doch je nach dem kommt es auch darauf an, wie lange das Programm zum messen läuft - ausser Nachrichten empfangen, muss es sonst ja nichts machen.

Doch, es macht in dem Event eine ganze Menge!
Das gesamte Procedere dauert 32ms, was mir viel zu lange ist (soll auf P100 unter 100ms laufen).
Ich messe mit dem OptimizeIt-Profiler, und wenn ich einfach nur ein print in die event-methode reingebe, hat auch getNextEvent fast keine Last....

lg

[bischi]

Ist mir ein Rätsel! Kannste mal ein bisserl Code posten?

MfG Bischi

PS: Kann ich das Messtool gratis für Windows bekommen? Wo?

[Lin728]

Der Profiler werter Thread.sleep() auch als Prozessorzeit, obwohl diese Methode keine Last erzeugt -> keine Last da.....

[bischi]

Kein Problem, hat Spass gemacht!

MfG Walfisch

[anda_skoa]

Original geschrieben von ceisserer
Der Profiler werter Thread.sleep() auch als Prozessorzeit, obwohl diese Methode keine Last erzeugt -> keine Last da.....

Es könnte sein, dass Thread.sleep() ein atomares Warten ist, das den Processtimeslot nicht freigibt, also wo es nicht zu einem vorzeitigen Prozess- oder Threadwechsel kommt.

Ciao,
_

[Lin728]

Hallo!

Doch, es ist nicht atomar es erfolgt ein Thread-Wechsel.
Nur zeigt der Compilier jeden Thread einzeln an, und dan an einer gemeinsamen Time-Line...