edigonzales
commented
1 year ago Mit --singlePass getestet. Gleicher Datensatz wie im Eingangsticket.
JVM: Info: End date 2022-11-21 21:13 validation took 00h:00m:28s.0168ms
JVM -Xcomp: Info: End date 2022-11-21 21:12 validation took 00h:01m:05s.0936ms
Native Image: Info: End date 2022-11-21 21:15 validation took 00h:01m:18s.0097ms
Mit -Xcomp ist man nahe an der "schlechten" Native Image Performance. -Xcomp kompiliert die Sache gleich zu Beginn runter und macht entsprechend keine Optimierungen zur Laufzeit. So habe ich es jedenfalls verstanden. Darum finde ich es "ähnlich" vom Verhalten wie AOT. Ob die ähnliche Performance aber auf das zurückzuführen ist, weiss ich nicht.
@claeis Was machen?
Die Performance des native images ist signifikant schlechter im Vergleich zur "puren" Java-Variante. Die Fruchtfolgeflächen https://s3.eu-central-1.amazonaws.com/ch.so.agi.geodata/ch.so.alw.fruchtfolgeflaechen_latest_xtf.zip dauern circa 8 Minuten mit der Java-Variante und 16 Minuten mit dem native image.
Da das native image in der Community Edition Variante nur SerialGC unterstützt, habe ich diesen auch für die JVM-Variante verwendet.
So wie ichs verstehe, ist leider der GC-Output des native image nicht identisch mit dem GC-Output der JVM-Variante und mir ist somit nicht klar, wie man diesen GC-Output analysieren könnte. Native image kennt
-XX:+PrintGC -XX:+VerboseGCaber kann ich keine File schreiben. JVM kennt-Xlog:gc*:file=<PATH_TO_GC_LOG_FILE>(ab Java 9).Vielleicht ist von der Charakteristik her die Aufgabe nicht wirklich native image geeignet? Long running und high throughput?
JVM:
Native image: