Heißt aber natürlich auch, bis zum Release bleibt das momentane Problem dann erst mal bestehen. Immerhin muss ich nun nicht weiter suchen.

Admin 4 ist JQuery und Material stuff ... Admin 5 wird React.

Ich denke wir brauchen erstmal was "fertiges" von Admin 5, dann kann man mal schauen, aber dadurch das quasi alles ein React rewrite ist ... vielleicht ;-)

Gibt es das Problem in der nächsten Major denn dann nicht mehr?

Im Objektbaum werden unter Hierarchien geladen, wenn man sie das erste mal aufklappt. Klappt man sie wieder zu (entweder einzeln oder über den Knopf in der Toolbar) dann werden sie nur ausgeblendet, aber nicht aus dem DOM entfernt. Schlimmer noch: Aktualisierungen werden bei den zugeklappten Knoten weiterhin eingetragen, aber nicht etwa, indem man den Wert der einzelnen Zellen updatet, sondern offenbar durch entfernen der DOM-Knoten und anschließendes Neu einfügen.

Da wundert mich der Performance-Drop absolut nicht mehr. DOM-Knoten löschen und einfügen ist so ziemlich das schlimmste, was man in einer Webanwendung hinsichtlich der Performance tun kann. Ist das eine Sache des FancyTree oder worin liegt das begründet? Es handelt sich ja auch nicht um einen einzelnen DOM-Knoten je Wert sondern eher 30 Stück, weil zahlreiche ungeordnete DOM-Elemente entfernt werden.

Das erklärt auch den weiteren Bug, dass offene Editoren z.B. in der Spalte "Name" hart geschlossen werden, wenn ein neuer Wert rein kommt, während man den Namen anpasst.

Das erklärt aber erstmal nur die CPU-Last und noch nicht den Speicherverbrauch. Entfernte DOM-Knoten sollte der Browser freigeben. In anbetracht dessen, dass ich 64 GB habe und davon 80% frei sind, stört der Speicherverbrauch aber erstmal nicht. Ich habe auch eine Speicheranalyse im Webbrower probiert. Hier sieht man, dass zyklisch Speicher geholt, aber auch zurück gegeben wird. Einen großen Anstieg erzeugt das erstmalige öffnen des Skript Editors (was grundsätzlich zu erwarten und auch okay ist). Die CPU-Last ist aber ein No-Go.

Verstärkt tritt das Problem übrigens auf, wenn man nebenbei Skripte offen hat und diese startet.

wenn man an den Skripten arbeitet = editiert
Auch das ist bekannt, dass da der Browser Probleme macht, Cache leeren hilft auch da.

@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:

Meint ihr echt, dass die paar Instanzen da den Kohl fett machen?

nein, das Backend hat damit -wie du im Eingangspost richtig festgestellt hast- nichts mit zu tun

Die Frage wäre ja mal: Geht es jemand anders auch noch so?

Ja, ich leere dann mal einfach den Cache.

Die Frage wäre ja mal: Geht es jemand anders auch noch so? Verstärkt tritt das Problem übrigens auf, wenn man nebenbei Skripte offen hat und diese startet. Es passiert aber auch so nach einiger Zeit im Hintergrund.

Meint ihr echt, dass die paar Instanzen da den Kohl fett machen? Der Raspberry PI selbst langweilt sich nämlich absolut und hat gar keinen Stress mit den Instanzen. Die SD-Karte sieht auch unauffällig aus (Write/Read Tests haben erwartbare Werte).

@apollon77 Das geht ja hier schneller als in jedem Chat. ;) - also ist das Problem doch irgendwie bekannt? Interessant ist dabei, dass die einzelnen Browser ja nicht alle die selbe JavaScript Engine nutzen. Trotzdem passiert das in allen Browsern. Sprich die Garbage Collection funktioniert nicht, weil noch irgendwelche Variablen irgendwelche Objekte halten, die aber nicht mehr gebraucht werden?

Die restlichen Adapter nutze ich aber alle.

Z. B. Ping und Discovery sind i.d.R. entbehrlich. Und bei genauerer Betrachtung mit Sicherheit auch noch andere.

Mir ist nicht ganz klar, was das verursacht

der Browser!

Kann ich Clientseitig die Objektaktualisierung zu Debugzwecken mal irgendwie abschalten? Dann wüsste ich sicher, ob es damit zu tun hat oder nicht (also nur die Anzeige, nicht die tatsächlichen Zustände). Falls das nur via JavaScript-Konsole geht, das bekomme ich hin. ;)

Du solltest unter tr-064.0 doch alle devices haben?

7 mal tr-064?