Java performance "AOT-Compiler"

G

Golgari

Grünschnabel
Hallo

Ich sitze gerade an einem größeren Java-Client-Projekt und muss die Performance steigern.
Am Code selber kann ich nicht viel machen (Profiling) und muss mir deshalb andere Wege suchen.
Da die Plattformunabhängigkeit bei diesem Projekt unwichtig ist, hat mich der Ansatz der AOT-Compiler interessiert. D.h gleich auf den Binärcode zu compelieren und damit die VM und den Bytecode zu überspringen.

Jetzt hab ich viele Artikel dazu gelesen, die aber aus der Zeit 2001-2003 stammen und auf Produkte referenzieren die es nicht mehr gibt.
Bis auf http://www.excelsior-usa.com/jetinternals.html sind alle anderen „verschwunden“
(gcj gibt’s auch noch)

Meine Frage: ist dieser Ansatz denn überhaupt noch lohnenswert? Und hat jemand schon Erfahrungen damit gemacht?Gibt es noch weitere Compiler?
 
Zuletzt bearbeitet:
Der falsche Ansatz *sorry*.

Wenn die App langsam läuft, dann hast du irgendwo ein Flaschenhals. Diesen solltest du suchen.
JDBC Treiber? Datenbank die nur falsch angesprochen wird? Irgendwelche RMI Sachen die unnötig sind? usw.

Um was für eine Art Programm handelt es sich?
 
Hallo!

Also ich wuerde auch nicht den weg ueber einen AOT (Ahead of Time) Compiler gehen, da der Performance Gewinn wenn ueberhaupt eher marginal ausfallen wird.
Wenn du an der Anwendung nichts machen kannst, solltest du vielleicht mal ein wenig mit den JVM Optionen herumspielen. Bei den heutigen JVMs kann man da schon sehr viel in Tunen (vor allem Garbage Collection ist hier ein grosses Thema). Du koenntest auch mal versuchen die Anwendung mit der Server JVM ( java ... - server ...) laufen zu lassen.
Ansonsten koenntest du auch mal die JRockit JVM von BEA ausprobieren. Das ist die schnellste JVM die ich kenne. (Ist frei verfuegbar)

Gruss Tom
 
hier handelt es sich um eine Steuergaräte-Diagnose SW die mit vielen anderen Komponenten kommunizieren muss, wo es sicher genügend Flaschenhälse gibt aber an denen ich nichts ändern kann/darf. Ein Erfolg währe schon den Start zu verkürzen.
Daher muss ich erstmal von "außen" Ansätze finden.
Ist der Ansatz denn prinzipiell möglich oder gewinnt man damit wenig Performance?
 
Oh… eine großes + an das Forum/an die Mitglieder … hier bekommt man ja sehr schnell Antwort

Ja diese Möglichkeiten (VM-optionen) teste ich gerade aus aber der Werbetext von http://www.excelsior-usa.com/jetinternals.html war einfach zu verlockend und ich bin dem dann nachgegangen. Und vielleicht hat jemand damit schon Erfahrung gemacht
 
Hallo!

Also wie gesagt mit GC Tuning kann man da schon sehr viel reissen (wenn man sich entsprechend auskennt). Weiterhin ist fuer schnelle Startup Zeiten eigentlich die -client JVM zu empfehlen wobei ein versuch mit -server nicht Schaden kann. Weiterhin kann es die Anwendung auch beschleunigen wenn man den Wert fuer den initialen Heap Speicher gleich auf den Wert fuer den maximalen Heapspeicher setzt also via:
java -Xms256m -Xmx256m de.tutorials.Main
Hmm, wenn Steuergaräte-Diagnose SW hast wie kommuniziert die denn mit den Endgeraeten? Ueber die Serielle Parallele Schnittstelle mit dem Java Communications API? Ich hab gestern in einer Newsgroup gelesen, dass das bei "unsachgemaesser" Anwendung ein Flaschenhals sein kann (ich glaube vor allem das Staendige Wechseln der Daten-Flussrichtung hat da Zeit gekostet). Als alternative dazu wurde das ebenfalls auf dem Java Communications API aufbauende RXTX Projekt genannt: http://www.rxtx.org/

Gruss Tom
 
Golgari hat gesagt.:
hier handelt es sich um eine Steuergaräte-Diagnose SW die mit vielen anderen Komponenten kommunizieren muss, wo es sicher genügend Flaschenhälse gibt aber an denen ich nichts ändern kann/darf. Ein Erfolg währe schon den Start zu verkürzen.
Daher muss ich erstmal von "außen" Ansätze finden.
Ist der Ansatz denn prinzipiell möglich oder gewinnt man damit wenig Performance?
Zum Vergrößern anklicken....

Etwas was zwar nicht die Geschwindigkeit ansich erhöht, aber die gefühlte Geschwindigkeit und die Akzeptanz ist wenn du dafür sorgst das solche Operationen grundsätzlich in einem eigenen Thread, am besten mit nem schönen Statusbalken, laufen lässst. (Falls das noch nicht so ist)
 
@ Thomas
Ok danke, ich werd mal nachschauen

@Christian
die empfundene Performance ist natürlich auch wichtig und der splash screen kann’s kürzer erscheinen lassen aber für die QM-Kriterien zählen leider nur Zahlen
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück