Récemment, dans l'étude de "JavaScript Advanced Programming", il y a une description des caractéristiques des chaînes. Le texte d'origine est à peu près comme suit: les chaînes dans ECMAScript sont immuables, c'est-à-dire, une fois les chaînes créées, leurs valeurs ne peuvent pas être modifiées. Pour modifier la chaîne enregistrée d'une variable, détruisez d'abord la chaîne d'origine, puis remplissez la variable d'une autre chaîne contenant la nouvelle valeur, par exemple:
La copie de code est la suivante:
var lang = "java";
lang = lang + "script";
Le processus d'implémentation de cette opération est le suivant: Créez d'abord une nouvelle chaîne qui peut contenir 10 caractères, puis le remplir de "java" et "script" dans cette chaîne. La dernière étape consiste à détruire les cordes originales "Java" et "Script", car ces deux chaînes sont inutiles. Cependant, dans les versions inférieures des navigateurs (comme IE6), la vitesse d'épissage des chaînes est un processus consommant des performances.
De là, je pense à Java. Le mécanisme de chaîne en Java est similaire à JS (c'est-à-dire qu'il ne peut pas être modifié après la création, et pour le changer, il ne peut que détruire la valeur d'origine), mais Java a un StringBuffer qui résout le problème de l'immuabilité des cordes, et JS n'a pas de méthode similaire. Mais nous pouvons simuler ce mécanisme tampon. Le principe est d'utiliser des tableaux pour l'épissage, le code source est le suivant:
La copie de code est la suivante:
fonction stringbuffer () {
this .__ Strings__ = new Array ();
}
StringBuffer.prototype.append = fonction (str) {
cette cordes .__ __. Push (str);
retourner ceci; // Fonctionnement de la chaîne pratique
}
StringBuffer.prototype.toString = function () {
Renvoyez ce .__ Strings __. JOIN ("");
}
/*test*/
var buffer = new StringBuffer ();
Buffer.APPEND ("Hello"). APPEND ("JavaScript");
var result = buffer.toString ();
alerte (résultat);
PS: L'adresse Gist est la suivante: https://gist.github.com/hehongwei44/fe71f10e4d2d9295aeab
Nous avons simulé le mécanisme, mais il y a une différence de performance entre cette méthode et l'épissage des chaînes. Nous pouvons le tester et le code de test est le suivant:
La copie de code est la suivante:
var d1 = new Date ();
var str = "";
pour (var i = 0; i <10000; i ++) {
str + = "texte";
}
var d2 = new Date ();
Document.Write ("Tester un coût:" + (d2.GetTime () - d1.getTime ()) / 1000 + "secondes" + "<br/>");
var obuffer = new StringBuffer ();
d3 = new Date ();
pour (var i = 0; i <10000; i ++) {
obuffer.append ("texte");
}
var sresult = obuffer.toString ();
d4 = new Date ();
Document.Write ("Tester deux coûts:" + (d4.GetTime () - D3.GetTime ()) / 1000 + "secondes");
Les résultats des tests sont les suivants: (Les résultats des tests peuvent être différents dans différents environnements):
1. Lorsque vous comparez 1000 fois comme base, l'exécution des deux est très rapide (millisecondes de base) et prend à peu près au même moment. Cette dernière différence entre la première ne dépassera pas 10 millisecondes.
2. Avec 10 000 fois comme base, le résultat de l'exécution est similaire à ce qui précède, mais le premier a plus de factures de téléphone sous IE6.
3. Avec 100 000 fois comme base, l'épissage de chaîne dans IE6 prend évidemment plus de temps, et d'autres navigateurs ne sont pas très différents, et certains sont plus courts que StringBuffer.
en conclusion
1. Lorsque le nombre de mots d'épissage est inférieur à 1 000 fois, utilisez hardiment le premier, et nous rencontrons rarement des milliers de temps d'épissage.
2. Les autres navigateurs n'ont aucun problème de performance avec l'épissage, principalement IE6. Si les temps d'épissage coûtent des dizaines de milliers ou des centaines de milliers, il est recommandé d'utiliser StringBuffer pour simuler IE6 seul.