Consommation de mémoire Redux [fermé]

23

Le cadre Redux favorise le paradigme immuable état / fonction pure, qui favorise la création d'un nouvel état à partir de l'état précédent en termes d'action en cours. L'applicabilité de ce paradigme est indubitable.

Une de mes préoccupations majeures est que, comme les réducteurs Redux renvoient avec impatience de nouveaux états des états précédents pour chaque action invoquée, le drain de mémoire massif (à ne pas confondre avec les fuites de mémoire) deviendrait un phénomène courant dans de nombreuses applications du monde réel. . Lorsque l'on considère que les applications Javascript s'exécutent normalement dans un navigateur sur les appareils d'un utilisateur moyen qui pourraient également exécuter plusieurs autres applications spécifiques à l'appareil et plusieurs autres onglets et fenêtres de navigateur, la nécessité de conserver la mémoire devient de plus en plus évidente.

Quelqu'un a-t-il réellement comparé la consommation de mémoire d'une application Redux à l'architecture traditionnelle de Flux? Si oui, pourraient-ils partager leurs conclusions?

000
la source
4
Je vote pour fermer cette question comme hors sujet car elle demande des informations de profilage de mémoire arbitraires.
L'avez- vous profilé?
Pourquoi devrais-je le profiler? Pour confirmer l'évidence? N'est-ce pas du bon sens que le fait de reproduire un objet similaire à maintes reprises entraîne une surcharge importante en termes d'utilisation de la mémoire? La réponse de @ Dan fournit un moyen de minimiser ce surcoût et c'est la meilleure réponse à ce jour.
000

Réponses:

30

C'est une préoccupation valable. Bien que je n'aie pas mesuré l'utilisation de la mémoire des applications Redux, je pense qu'avant de vous engager à utiliser Redux (ou tout autre framework d'ailleurs), vous devez créer des tests de stress qui émulent les quantités de données, modifient la fréquence et l'intensité de calcul de l'application que vous vont construire. Utilisez ces tests de résistance avant de prendre des décisions technologiques pour savoir si l'adoption de l'immuabilité fonctionne dans votre cas particulier.

Notez que parfois les gens sont confus à propos de Redux et supposent qu'à chaque action, l'arbre d'état doit être cloné profondément. Ce n'est absolument pas le cas. Seules les pièces qui ont changé doivent changer leurs références. Par exemple, si une action entraîne une modification d'un élément dans un tableau, en effet, cet élément et le tableau devront être copiés, cependant , tous les autres éléments du tableau conserveront leur identité. Parce que la plupart du temps, les actions sont très ciblées et affectent quelques clés d'état, et parce que Redux encourage la normalisation des données afin que les structures de données ne soient pas profondément imbriquées, cela pose beaucoup moins de problèmes pour les applications Web typiques qu'on pourrait l'imaginer.

Vous souhaiterez également explorer l'utilisation de bibliothèques comme Immutable.js qui implémentent efficacement des listes et des cartes immuables en utilisant le partage structurel en interne. De cette façon, la modification de quelques éléments dans une liste n'implique pas autant de copie car en interne la plus grande partie de la mémoire est partagée entre différentes versions de la structure de données.

Mais au final, la seule façon de le dire est d'écrire les tests de résistance qui imitent étroitement l'utilisation prévue de votre application et de mesurer l'efficacité par vous-même.

Dan
la source
10
Ne soyez pas si rapide pour passer à Immutable.js. Cela devient un gros porc de mémoire dans notre cas. Immutable.js prend vos objets simples (vraisemblablement) propres et les instancie en monstres assoiffés de mémoire. Jetez un œil à cet exemple: jsfiddle.net/sn70x2p6 Après le chargement, l'onglet prend 61 000 Ko de mémoire. Après avoir fait un million d'objets simples, c'est 211 000 Ko. Fou. Maintenant, cliquez sur "rendre immuable" et voyez ce qui se passe. Il passe à plus de 1 Go de mémoire. Votre expérience peut différer, mais pas beaucoup.
Olav Kokovkin