Sicher nicht.
Ich weiß nicht wie gut Du dich mit Java auskennst aber basierend auf deiner gelieferten Funktion und den Änderungen gehe ich davon aus das es eher ein geringer Schulkenntnisstand ist.
Der code
static { final long mem = Runtime.getRuntime().maxMemory(); //we consider <640MB as low memory if (mem < lowMemory * 1024 * 1024) isLowMemory = true; else isLowMemory = false; }
wird beim Laden der Klasse genau EINMAL ausgeführt und speichert das Ergebnis der Prüfung in einer Variable. Das ist völlig ausreichend für die weitere Nutzung da wir hier eine Entscheidung treffen.
ìsLowMemoryEnvironment()` liefert das Ergebnis der Variable nun immer wieder zurück. Das hat zwei Vorteile:
Der Java JVM bytecode für meine Funktion sind genau zwei Befehle, bei deiner Version sind es 15. (Also im Interpretermodus schon mal Faktor 7 mehr)
Die zwei JVM bytecode ops können vom JIT (Just in Time compiler) schnell in die Klassen integriert werden wo sie genutzt werden da es so klein ist. Bei deinem Code dauert das einige Compilerzyklen mehr.
Das ist insofern ziemlich tragisch da (wie du sicherlich analysiert hast) diese Funktion unter anderem in DatenFilm verwendet wird. Dies ist die Klasse welche die Filme abbbildet. So wird also die Funktion beim Laden der Filmliste derzeit ca. 500.000 mal aufgerufen. Deine ist Faktor 7 langsamer…
Weiterhin hat deine Funktion keine javadoc konforme Dokumentation. Gut, meine hat gar keine aber die Funktion ist Kategorie trivial.
getRuntime() liefert keine byte value zurück, sondern die Klasseninstanz Runtime. maxMemory liefert byte zurück.
2 GB RAM sind hier gerechnet 2048 * 1024 * 1024 und nicht 2000 * 1024 * 1024, aber das ist ein zu vernachlässigender Fehler.
Der Kernfehler liegt in deinem Kommentar “we consider < 2000MB als low memory”. Hierbei beglückwünsche ich dich dazu, durch eine kleine Änderung im Code SÄMTLICHE Geschwindigkeitsoptimierungen für alle Nutzer dauerhaft abzuschalten wenn ich deinen Code verwenden würde.
Du fragst dich sicherlich warum. Hier die Erklärung:
Du hast auf github gepostet als issue das Programm schmiert ab bei deinem Rechner mit 2GB RAM. daher siehst Du 2GB wohl als zu wenig für MV an.
Ich kann dir versichern MV läuft auch mit nur 512MB JVM RAM. Nicht schön aber es läuft…
Wo ist der Fehler? Runtime.maxMemory() liefert den maximal nutzbaren Speicher für die jeweilige JVM zurück. Das hat rein gar nichts mit dem physikalischen RAM des Systems zu tun!
Wenn ich dir nun sage das alle Anwender von MV standardmäßig eine in den config files definierte max JVM RAM größe von 1GB haben wären sie gemäß deinem code alle low memory environment. Dies würde z.B. dafür sorgen das die Dekompression der Filmliste mit deutlich angezogener Handbremse ablaufen würde und bei der Datenbank sämtliche Caches deaktiviert werden und somit zu eklatanten Geschwindigkeitseinbrüchen führen.
Abschließend (und nach vielen vielen Stunden vor einem Profiler um die Geschwindigkeit von MV zu optimieren) kann ich dir sagen das meine Funktion ziemlich gut ist, genau das tut was sie soll und deine Version - höflich formuliert - suboptimal ist.
Es gibt in MV deutlich andere Baustellen die langsamer sind und auch unnötig Speicher noch verbrauchen.
Und es wird dein Problem nicht lösen welches Du bisher in dem anderen Fred auch nicht weiter erläutert hast damit man dir helfen kann.
Ich habe - obwohl es mir eigentlich nicht passt Lehrstunden in Java zu geben - bemüht das ganze ausführlich zu beschreiben wieso der change schlecht ist. Ich bitte dich daher um eines: bitte lerne Java (und nicht nur auf Schul- oder Uni Anfangsniveau), schau dir den Code im gesamten Kontext an, nutze einen Debugger und lerne das System kennen bevor Du versuchst durch trial and error etwas zu optimieren was keinen Fehler hat.
Es ist nicht böse gemeint, aber ich wechsel an meinem Auto auch keine Bremsscheiben und -belege weil ich mal in einer Anleitung gesehen habe wie es geht. Ich bin kein Mechaniker und habe keine wirkliche Ahnung davon.
