Alles anzeigenDanke für die Blumen
Dank der Mithilfe von okeks versteh ich nun ein bisschen besser, warum der Memory (Arbeitsspeicher) voll läuft und ich versuche das mal so verständlich zu erklären:
Jedes mal, wenn ein Tab oder ein Fenster in einer Lightbox geöffnet wird, wird in diesem eine LSSM-Instanz erzeugt. Das ist zugegeben nicht sonderlich performant, aber sollte in erster Linie kein Problem darstellen und vor allem keine "Out of Memory" Fälle generieren.
Normalerweise ist der Browser und JavaScript so schlau, den Inhalt des Speichers zu löschen, wenn er nichtmehr benötigt wird. Das ist sehr leicht gesagt aber eigentlich ein großes Problem, denn blöderweise ist unentscheidbar, wann ein Objekt als "nicht mehr benötigt" zählt. d.h. der Garbage-Collector (der ist dafür zuständig ein bisschen im Arbeitsspeicher aufzuräumen) von JavaScript versucht so viel wie möglich von dem zu entfernen, was nicht mehr benötigt wird. Leider ist das weder in der Theorie noch in der Praxis vollständig möglich, d.h. man muss damit rechnen, dass immer ein bisschen was übrig bleibt.
Was ist jetzt aber das eigentliche Problem? Jedes mal, wenn ein Fenster entladen wird (man wechselt auf eine andere Seite, schließt die lightbox, etc.) sollte der Arbeitsspeicher, der dafür benutzt wurde, freigegeben werden. Ist der LSSM nun aktiv, so verhindert er dies. Im Arbeitsspeicher sammeln sich also auch LSSM-Instanzen von bereits geschlossenen Fenstern an. Das ist natürlich kacke, weil diese sind ja eh nichtmehr nutzbar (Fenster existiert nichtmehr) und benötigt werden sie auch nicht mehr. Warum werden diese Instanzen vom Garbage-Collector nicht weggeräumt? Ehrlich: Ich weiss es nicht!
Aktuelles Ziel ist es erstmal kurzfristig das so hinzubekommen, dass der Datenmüll weggeräumt wird. Ich hab schon ein paar Kleinigkeiten versucht, aber funktioniert hat das alles blöderweise noch nicht.Wenn das nicht klappt (auch wenns klappt, aber dann ist es ein langfristigeres Ziel) müssen wir den Core, also den LSSM-Kern, umschreiben. Das wird ziemlich sicher in einem Update des installierten User-Scripts führen. Theoretisch sollte Tampermonkey damit automatisch melden, wenn es soweit ist, aber wir werden trotzdem auf jeden Fall nochmals Hinweise an verschiedenen Stellen geben, damit man ein Update manuell triggern kann. Was für Änderungen hab ich da vor? Relativ einfach (haha, sagt er so leicht…): Der Core wird nurnoch einmal pro Tab geladen. Öffne ich nun eine Lightbox (z.B. einen Einsatz) in diesem Tab, so verwendet dieses Sub-Fenster den selben Core. Das sollte nicht nur die Ladezeiten des LSSM verbessern sondern auch die "Out of Memory" Probleme lösen. Bis es soweit ist braucht es aber sicher noch Zeit und außerdem wurde mir geraten, die anstehende Klausurenphase nicht ganz mit LSSM auszufüllen sondern auch ab und zu einen Blick auf den Stoff für die Prüfungen zu werfen. Wie auch immer: Ich seh das natürlich als spannendes Projekt und eine gute Chance, mein Wissen zu erweitern.
Im Spoiler pack ich für Interessierte (und die es werden wollen) mal noch eine Info, was unser Core eigentlich ist, was er macht und wieso wir den brauchen:
Ich wünsche euch eine schöne restliche Woche, genießt die Tage und freut euch auf ein hoffentlich baldiges Update,
euer Jan
Diese Ausführlichen Erklärungen erinnern mich an die guten alten Zeiten als Sebastian einen Fehler im Spiel erklärt hat 
Ich hab mal ne Frage zum Share Alliace Post.
Wenn ich die geplanten Einsätze mit dem {{beginAt}} freigebe, fehlt mir eine Zeit EInheit dahinter. Ich kann ja nicht Schreiben {{beginAt}} Stunden , und dabei beginnt der Einsatz schon in 5 Minuten...
Ich hoffe du verstehst was ich meine?
