@derreisende77 sagte in Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten:
@plusterkopp String.intern() wurde in früheren Versionen eingesetzt.
Und wenn Du eine Behauptung bzgl. Nichtzutreffen einer Verlangsamung aufstellst solltest Du das bitte begründen
Steht neben meinem Namen ENTWICKLER? Begründen könnte ich das nur mit einem Vergleich von mit/ohne. Das würde bedeuten: eine Version von MediathekView mit und eine ohne String.intern(). Darauf bezieht sich doch Deine Verlangsamungsaussage, oder?
Wir reden hier ja nicht davon, daß die Map-Variante schneller ist, oder daß es generell schneller ist, eine Methode nicht aufzurufen, als sie aufzurufen. Das steht außer Frage. Und wenn ich bislang schrieb String.intern, könnte man das auch als irgendeine Art der Stringzusammenlegung verstehen. Ob nun nur das langsame String.intern, die CHM-Version, oder das verzögerte Zusammenlegen mittels Timerjob (der aber den Nachteil hat, daß man erstmal doch den vollen Heap braucht).
Wie gesagt, es ging darum, daß das Programm jetzt mehr Heap braucht als früher. Wenn Euch die Geschwindigkeit beim Anlegen der Filmliste wichtiger ist als der Heap, dann laßt es halt so.
Seiteneffekte von String intern u.a. in Bezug auf die maximale String table size und Auswirkungen auf den Speicherverbrauch kannst Du bei Oracle et al nachlesen. Desweiteren gibt es zig Performance Artikel weshalb String.intern scheisse ist. Ein Beispiel für die tolle Performance findest Du hier
Das SOF Artikel ist etliche Jahre alt und neuere Kommentare weisen durchaus darauf hin, daß das Stringtable-Problem nicht mehr so dramatisch ist wie zu JDK-1.6 Zeiten. Aber trotzdem braucht String.intern Zeit. Auf meinem ollen i7-3770 etwa 500ns für 1M unterschiedliche Strings mit völlig überfüllter Stringtabelle.
Wenn Ihr also 500.000 DatenFilm-Instanzen habt mit je 13 String-Feldern (den Optional-Kram nicht mitgerechnet), dann wären das 3s, wahrscheinlich aber weniger, wenn man das intelligent mit CHM macht.
String Deduplication wird evtl. bei der win32 Version noch nicht benutzt da der commit dafür noch nicht gemerged wurde, die macOS Version benutzt das. Weiterhin wird das ganze in den nächsten Versionen eh komplett umgestellt womit ich mir eine verbesserte Speichernutzung erhoffe. Das muss aber alles getestet werden.
Warum auch immer Ihr da nach OS unterscheidet… Es wird auch bei der Win64-Version nicht benutzt. Mir wie gesagt egal, kann man ja konfigurieren.
Welchen Threshold meine ich? -XX:StringDeduplicationAgeThreshold. Dieser bestimmt nach welchem GC Zyklus das erste Mal bestimmte Objekte angepasst werden.
Hier mal die VM-Optionen, die ich so sehe:
uintx StringDeduplicationAgeThreshold = 3 {product} {default}
bool StringDeduplicationRehashALot = false {diagnostic} {default}
bool StringDeduplicationResizeALot = false {diagnostic} {default}
uintx StringTableSize = 65536 {product} {default}
bool UseStringDeduplication = true {product} {command line}
Möglicherweise müßtet Ihr das auf 1 setzen, aber wenn ich mir mit
-Xlog:logging=trace,gc*=info,safepoint=info,ergo*=info,classhisto*=trace,gc+ergo+cset=trace:file="gc.log":time,tags,level:filesize=1G
mal euer gc.log ansehe, habt Ihr auch nach dem Erzeugen der meisten Strings noch ausreichend GCs, um alle Strings zu erwischen.
Und nächstes Mal sind wir nicht so auf Krawall gebürstet, Herr ENTWICKLER, gelle?
drückerchen!
