Implications sur les performances de la définition de méthodes via un prototype ou un constructeur en JavaScript

En JavaScript, deux approches existent pour créer des « classes » avec des fonctions publiques : en utilisant le prototype ou le constructeur. La méthode 1 attribue des fonctions aux instances via le constructeur, tandis que la méthode 2 utilise le prototype pour partager des fonctions entre toutes les instances.

Bien que la méthode 2 soit souvent considérée comme plus efficace, priver les instances de variables d'instance privées constitue un inconvénient majeur. . Cependant, la création apparente de copies de fonctions en double pour chaque instance par la méthode 1 se produit-elle réellement dans la pratique ?

Preuves empiriques de JsPerf Benchmark

L'analyse comparative JsPerf suggère que la méthode 2 (prototype ) surpasse en effet la Méthode 1 (constructeur) en terme de rapidité.

Pratique Implications

Bien que cette différence soit évidente dans les benchmarks, sa pertinence dans les applications du monde réel est discutable. Même dans les scénarios comportant un nombre important d'instanciations d'objets (par exemple, 10 000 par image), il est peu probable que cette micro-optimisation réduise les goulots d'étranglement des performances.

Recommandations

En cas d'optimisation la performance est cruciale, il est conseillé de déclarer les méthodes via le prototype. Sinon, la méthode 1 offre une plus grande flexibilité et adhère aux conventions courantes de programmation orientée objet. De plus, l'utilisation de propriétés privées indiquées par un préfixe de soulignement (par exemple, _process()) améliore l'encapsulation et décourage la modification directe.