Redux-Speicherverbrauch [geschlossen]

Das Redux-Framework bevorzugt das Paradigma von unveränderlichem Zustand / reiner Funktion, das die Erzeugung eines neuen Zustands aus dem vorherigen Zustand im Hinblick auf die aktuelle Aktion fördert. Die Anwendbarkeit dieses Paradigmas ist unbestreitbar.

Ein wichtiges Anliegen von mir ist, dass, da die Redux-Reduzierer eifrig neue Zustände aus früheren Zuständen für jede aufgerufene Aktion zurückgeben, eine massive Speicherentleerung (nicht zu verwechseln mit Speicherlecks) in vielen Anwendungen der realen Welt zum alltäglichen Ereignis wird . Wenn man bedenkt, dass Javascript-Anwendungen normalerweise in einem Browser auf Geräten eines Durchschnittsbenutzers ausgeführt werden, auf denen auch mehrere andere gerätespezifische Anwendungen und mehrere weitere Browser-Registerkarten und -Fenster ausgeführt werden können, wird die Notwendigkeit, Speicherplatz zu sparen, immer deutlicher.

Hat jemand tatsächlich den Speicherverbrauch einer Redux-Anwendung mit der traditionellen Flux-Architektur verglichen? Wenn ja, könnten sie ihre Erkenntnisse teilen?

Dies ist ein berechtigtes Anliegen. Obwohl ich die Speichernutzung von Redux-Anwendungen noch nicht gemessen habe, sollten Sie vor der Verwendung von Redux (oder eines anderen Frameworks) Stresstests erstellen, die die Datenmengen, die Änderungshäufigkeit und die Rechenintensität der von Ihnen verwendeten Anwendung emulieren werden bauen. Verwenden Sie diese Stresstests, bevor Sie technologische Entscheidungen darüber treffen, ob die Übernahme der Unveränderlichkeit in Ihrem speziellen Fall funktioniert.

Beachten Sie, dass Redux manchmal verwirrt ist und dass bei jeder Aktion der Statusbaum tief geklont werden muss. Dies ist absolut nicht der Fall. Nur die Teile, die sich geändert haben, müssen ihre Referenzen ändern. Zum Beispiel, wenn eine Aktion eine Änderung an ein Element in einem Array verursacht, in der Tat, dass Element und das Array müssen kopiert werden, aber auch alle anderen Elemente im Array werden ihre Identität behalten. Da Aktionen in den meisten Fällen sehr zielgerichtet sind und sich auf einige wenige Statusschlüssel auswirken und Redux zur Normalisierung von Daten aufruft, damit die Datenstrukturen nicht tief verschachtelt werden, ist dies für typische Webanwendungen weitaus weniger problematisch, als man denkt.

Sie sollten auch Bibliotheken wie Immutable.js verwenden, die unveränderliche Listen und Maps effizient implementieren, indem Sie die strukturelle Freigabe intern verwenden. Auf diese Weise wird beim Ändern einiger Elemente in einer Liste nicht so viel kopiert, da intern der größte Teil des Speichers von verschiedenen Versionen der Datenstruktur gemeinsam genutzt wird.

Die einzige Möglichkeit, dies zu beurteilen, besteht letztendlich darin, die Stresstests zu schreiben, die die beabsichtigte Verwendung Ihrer App genau nachahmen, und die Effizienz selbst zu messen.