principes d'optimisation js

Cet article partage avec vous les principes de l'optimisation js. Le contenu est plutôt bon. Les amis intéressés peuvent y jeter un œil

.

Tout d'abord, contrairement à d'autres langages, l'efficacité de JS dépend en grande partie de l'efficacité du moteur JS. En plus des avantages et des inconvénients de la mise en œuvre du moteur, le moteur lui-même adoptera également des stratégies d'optimisation pour certains modèles de code spéciaux. Par exemple, les moteurs JS de FF, Opera et Safari ont spécialement optimisé l'opération de concaténation de chaînes (+). Évidemment, pour obtenir une efficacité maximale, vous devez comprendre le tempérament du moteur et essayer de répondre à ses goûts. Par conséquent, pour différents moteurs, les optimisations apportées sont très susceptibles d'être contradictoires.

Et si vous faites de la programmation Web multi-navigateurs, le plus gros problème est IE6 (JScript 5.6) ! Car sans hotfix, le bug de garbage collection du moteur JScript fera que ses performances dans les applications réelles ne seront pas du même ordre de grandeur que celles des autres navigateurs. Par conséquent, optimiser dans cette situation revient en fait à optimiser pour JScript !

Le premier principe est donc Optimiser uniquement pour IE6 (JScript 5.6 non corrigé ou version antérieure)  !

Si votre programme a été optimisé pour des performances acceptables sous IE6, il n'y aura fondamentalement aucun problème de performances sur les autres navigateurs.

Par conséquent, veuillez noter que bon nombre des problèmes dont je parle ci-dessous peuvent être complètement différents sur d'autres moteurs. Par exemple, l'épissage de chaînes dans une boucle est généralement considéré comme nécessitant Array.join, mais en raison de moteurs tels que SpiderMonkey, ils ont optimisé l'opération "+" sur les chaînes. Par conséquent, utiliser Array.join n'est pas aussi efficace que d'utiliser directement "+". Mais si l’on considère IE6, cette différence d’efficacité sur les autres navigateurs ne vaut pas du tout la peine d’être mentionnée.

L'optimisation JS présente toujours des similitudes avec l'optimisation dans d'autres langages. Par exemple, ne vous précipitez pas dans l’optimisation dès le début, cela n’a aucun sens. La clé de l’optimisation reste de se concentrer sur l’endroit le plus critique, à savoir le goulot d’étranglement. D’une manière générale, les goulots d’étranglement apparaissent toujours dans des boucles à grande échelle. Cela ne veut pas dire que les boucles elles-mêmes présentent des problèmes de performances, mais qu’elles peuvent rapidement amplifier d’éventuels problèmes de performances.

Le deuxième principe est donc de prendre les boucles à grande échelle comme objet d'optimisation principal.

Les principes d'optimisation suivants n'ont de sens que dans les boucles à grande échelle. Cela n'a fondamentalement aucun sens de faire une telle optimisation en dehors du corps de la boucle.

À l'heure actuelle, la plupart des moteurs JS sont interprétés et exécutés. Dans le cas d'une exécution interprétée, l'efficacité des appels de fonction est faible dans toutes les opérations. De plus, des chaînes d’héritage de prototypes trop profondes ou des références à plusieurs niveaux réduiront également l’efficacité. Dans JScript, la surcharge des références de niveau 10 représente environ la moitié de la surcharge d’un appel de fonction vide. La surcharge des deux est bien supérieure à celle d’opérations simples (telles que quatre opérations arithmétiques).

Le troisième principe est donc d'essayer d'éviter des niveaux de référence excessifs et des appels de méthodes multiples inutiles .

Il est important de noter que dans certains cas, ce qui semble être un accès à une propriété est en réalité un appel de méthode. Par exemple, tous les attributs DOM sont en réalité des méthodes. Lors du parcours d'une NodeList, l'accès de la condition de boucle à nodes.length ressemble à une lecture d'attribut, mais est en réalité équivalent à un appel de fonction. De plus, dans l'implémentation d'IE DOM, childNodes.length doit être recompté via un parcours interne à chaque fois. (Mon Dieu, mais c'est vrai ! Parce que j'ai mesuré que le temps d'accès de childNodes.length est proportionnel à la valeur de childNodes.length !) Cela coûte très cher. Par conséquent, enregistrer nodes.length dans une variable js à l'avance peut certainement améliorer les performances de traversée.

C'est aussi un appel de fonction, et l'efficacité des fonctions définies par l'utilisateur est bien inférieure à celle des fonctions intégrées au langage, car cette dernière est un wrapper pour les méthodes natives du moteur , et le moteur est généralement c, écrit en c++, java. De plus, pour la même fonction, le coût des constructions de langage intégrées est généralement plus efficace que celui des appels de fonctions intégrées, car les premiers peuvent être déterminés et optimisés pendant la phase d'analyse du code JS.

Le quatrième principe est donc d'essayer d'utiliser les propres constructions et fonctions intégrées du langage .

Voici un exemple de la méthode String.format haute performance. L'implémentation traditionnelle de String.format consiste à utiliser String.replace(regex, func). Lorsque le modèle contient n espaces réservés (y compris ceux répétés), la fonction personnalisée func est appelée n fois. Dans cette implémentation hautes performances, chaque appel de format effectue uniquement une opération Array.join puis une opération String.replace(regex, string) Les deux sont des méthodes intégrées du moteur sans aucun appel de fonction personnalisé. Deux appels de méthode intégrés et un nombre n d'appels de méthode personnalisés, c'est la différence de performances.

sont également des fonctionnalités intégrées, mais il existe toujours des différences de performances. Par exemple, les performances d'accès aux arguments dans JScript sont très médiocres, rattrapant presque celles d'un appel de fonction. Par conséquent, si une fonction simple avec des paramètres variables devient un goulot d'étranglement en termes de performances, vous pouvez apporter des modifications internes et ne pas accéder aux arguments, mais les gérer via un jugement explicite des paramètres.

Par exemple :

Code Java

1. fonction somme() {

2. var r = 0

3.  pour (var i = 0; i

4. r += arguments[i];

5. } > 

   return
r; 🎜>Cette somme est généralement appelée avec un petit nombre de paramètres, et nous espérons améliorer ses performances lorsqu'il y a moins de paramètres. Si modifié par :

7. Code Java

function sum() {

switch

(arguments.length) {

cas

1. 1 : retour

   arguments[
0
2. ]

cas

3. 2 : retourarguments[0] + arguments[1];

4.  

   cas 3 : retour arguments[0] + arguments[1] + arguments[2]

5. > 4 : retour arguments[0] + arguments[1] + arguments[2] + arguments [3];

6. > var r = 0

7.  pour (var i = 0; i

8.      r += arguments[i]; >

                                                                                               }
En fait, il ne sera pas beaucoup amélioré, mais s'il est modifié par :

11. Code Java

12. fonction somme(a, b, c, d, e, f, g) {

var r = une ? b ? c ? a + b : a :
0

 

si
(g === non défini)

retour

r; 

1.  pour

   (var i =
6
2. ; i r += arguments[i]

3. } 

4.  

   retour r; 

   } 

sera bien amélioré (au moins 1x plus rapide).

Le dernier est le cinquième principe, qui est souvent l'obstacle de performance le plus important dans les applications réelles, à savoir minimiser la création d'objets inutiles.

Il y a un certain coût pour créer l'objet lui-même, mais ce coût n'est en réalité pas élevé. Le problème le plus fondamental est que L'algorithme de planification de récupération de place extrêmement stupide de JScript entraîne une grave dégradation des performances à mesure que le nombre d'objets augmente (selon les personnes de Microsoft elles-mêmes, la complexité est O(n^2) ).

Par exemple, notre problème courant d'épissage de chaînes, grâce à ma vérification de test, la simple création d'objets de chaîne plusieurs fois n'est pas du tout la cause de mauvaises performances. Le pire est la surcharge de garbage collection inutile lors de la création d’objets. La méthode Array.join ne crée pas d'objets chaîne intermédiaires, réduisant ainsi la foutue surcharge de garbage collection.

Par conséquent, si nous pouvons convertir la création d'objets à grande échelle en une seule instruction, ses performances seront grandement améliorées ! Par exemple, en construisant le code puis en l'évaluant - en fait, le projet PIES travaille sur un générateur d'objets spécialisé à grande échelle basé sur cette idée...

Ça y est. Ce sont les cinq principes de l'optimisation JS que j'ai résumés.

Republié depuis le blog technologique de ---------------hax http://hax.iteye.com/blog/126859

Recommandations associées :

l'optimisation js fonctionne pour IE6.0 (arrangement détaillé)_javascript Conseils

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!