Fermer

février 23, 2019

Comparaison des performances des composants réactifs


Les composants fonctionnels mémorisés dans React valent-ils la peine de migrer vers aujourd'hui? Combien de gain de performance apportent-ils? Nous testons et découvrons.

Facebook a récemment annoncé de nouvelles fonctionnalités telles que React.memo, React.lazy et ainsi que quelques autres fonctionnalités . React.memo a particulièrement attiré mon attention, car il ajoute un autre moyen de construire un composant. Memo est une conception permettant de mettre en cache le rendu d'un composant fonctionnel pour l'empêcher de le restituer avec les mêmes accessoires. Ceci est un autre outil qui devrait figurer dans votre toolbelt lors de la création de votre application Web, mais je me suis demandé combien d'amélioration constituait une amélioration des composants fonctionnels mémorisés. Cela a conduit à une plus grande question: Vaut-il la peine de passer le temps de migrer des composants maintenant ou puis-je attendre?

La seule façon de prendre cette décision serait de la baser sur des données, et il existe un manque flagrant de données quantitatives sur le sujet. L’équipe de React fournit des outils de profilage permettant de profiler votre code individuel, mais il n’ya pas de chiffres de performance généralisés en ce qui concerne les nouvelles fonctionnalités. On comprend pourquoi les chiffres généraux manquent, car chaque composant est personnalisé et il est difficile de déterminer comment cela fonctionnera pour chaque application Web. Mais comme je voulais obtenir des indications sur ces chiffres, je me suis donc fixé le chemin pour obtenir des chiffres de performance sur les différentes manières de construire des composants afin de prendre des décisions éclairées quant à la migration potentielle de code.

À partir de React 16.6.0, il existe quatre façons. de construire un composant: une classe qui étend le composant, une classe qui étend PureComponent, un composant fonctionnel et désormais un composant fonctionnel mémoisé. Théoriquement, il existe un ordre de performance (moins performant que le plus performant):

  1. Composant d'extension de classe
  2. PureComponent d'extension de classe
    1. Met en oeuvre la méthode shallComponentUpdate en effectuant une comparaison des propriétés et des états peu profonds avant le recalage
  3. .
    1. Plus rapide parce qu'il n'instancie pas les accessoires et n'a pas d'événements de cycle de vie
  4. Composant fonctionnel mémoisé
    1. Potentiellement encore plus rapide en raison de tous les avantages des composants fonctionnels. De plus, il n'est pas rendu à nouveau si les accessoires sont identiques à un rendu précédent

Etant donné que je voulais chiffrer les performances, je pensais qu'obtenir des temps de rendu pour le même composant en utilisant différentes implémentations serait un bon moyen de contrôler les variables.

Après avoir décidé de ce que j'allais tester, je devais trouver un moyen d'effectuer le test. Malheureusement, c’est un peu plus compliqué depuis que React a déconseillé de réagir à react-addons-perf, ce qui nous permettait de synchroniser les composants React. Heureusement, j'ai trouvé quelqu'un qui avait le même objectif que moi et qui a construit réact-composant-benchmark qui est une excellente petite bibliothèque pour l'exécution de tests de performance de composants. De plus, cela m'a donné la possibilité de tester les temps de montage, de mise à jour et de démontage, ce qui m'a permis de mieux comprendre.

Je souhaitais configurer un composant simple pour pouvoir tester l'infrastructure réelle de rendu, de sorte que la méthode de rendu est juste un simple monde bonjour. Je les ai configurés comme un test de plaisanterie simple afin que chaque test exécute le composant et imprime les résultats. En outre, il était très facile d'obtenir tous les résultats en exécutant simplement le test du fil . J'ai exécuté le test de référence trois fois avec 20 échantillons à chaque fois. Les analyses 1 et 2 avaient tous les tests exécutés dans le même lot, et une troisième exécution a été effectuée en isolant chaque ensemble de composants pour l'exécution du test afin d'éliminer toute mise en cache. J'ai un exemple de projet lié ci-dessous pour que vous puissiez voir tout le code.

Code du composant:

 return (
Hello World!
);

Pour commencer le test, je pensais que les chiffres sauvegarder le classement de performance théorique que j'ai énuméré ci-dessus. J'étais plus qu'un peu surpris par la différence de performances.

Mount

Les essais 1 et 2 ont montré que PureComponents mettait environ 15 à 19% plus de temps à charger que Component, ce qui était un peu inattendu puisque Component et PureComponent devaient avoir la même mise en œuvre. Les composants fonctionnels étaient encore plus rapides à charger que les composants de 26% à 28%. Les composants fonctionnels mémorisés étaient au même niveau que PureComponents ou plus rapidement, à l’exception du blip de l’analyse 2.

L’exécution autonome a montré que les composants fonctionnels mémoisés présentaient des temps de montage nettement meilleurs que les autres.

Note latérale: Je voulais include Run 2 justement à cause du blip qui a entraîné l’extension aberrante du composant mémoisé afin de préciser qu’il s’agit de chiffres approximatifs pouvant encore améliorer la précision. Une partie de l'inexactitude est due au fait que React n'a pas été en mesure de tester rigoureusement les composants (plusieurs temps de rendu avec des moyennes).

 React

Mise à jour

Aucune mise à jour effectuée depuis nos mises à jour. DOM, ces chiffres étaient un peu plus conformes à mes attentes.

Pour les analyses 1 et 2, l'implémentation de PureComponent est légèrement plus rapide (4% à 9% plus rapide) que Component. Les composants fonctionnels sont 7% à 15% plus rapides que Component. Les composants mémoisés sont environ 25% plus rapides que Component.

Les nombres autonomes ne montrent pas le même gain de performances lors de la mise à jour, mais le composant fonctionnel mémo est toujours plus performant dans tous les tests que Component.

 Réagissez

À démonter

Il n’existe aucun vainqueur dans le chronométrage à démonter, à part les composants fonctionnels mémoisés exécutés plus rapidement que les autres, quel que soit le résultat. Je dirais que le temps de démontage n'est pas aussi critique puisqu'il n'y a pas de gagnant clair. Une observation intéressante est que les composants fonctionnels mémorisés ont obtenu de meilleurs résultats que les composants fonctionnels.

 React

Les chiffres indiquent une amélioration significative des performances lorsque vous passez de composant simple à composant pur ou à composant fonctionnel. Si vous avez besoin d'événements de cycle de vie, migrez vers PureComponent. Et si votre composant n’a pas besoin d’événements de cycle de vie, migrez-le en composant fonctionnel mémorisé. S'agissant de nombres généralisés, votre composant peut bénéficier de différentes manières lors de l'optimisation des performances. Après avoir vu ces chiffres, je vais passer aux composants fonctionnels dans la mesure du possible.

Consultez le dépôt pour le code complet et les résultats .


Les commentaires sont désactivés en mode Prévisualisation.

.




Source link