Maison > Article > interface Web > Explication détaillée de la concaténation de chaînes dans les compétences javascript_javascript
Récemment, lors de l'étude de "Javascript Advanced Programming", il y a eu une description des caractéristiques des chaînes. Le texte original est à peu près le suivant : Les chaînes dans ECMAScript sont immuables, c'est-à-dire qu'une fois les chaînes créées, leurs valeurs sont impossibles à modifier. Pour modifier la chaîne stockée dans une variable, détruisez d'abord la chaîne d'origine puis remplissez la variable avec une autre chaîne contenant la nouvelle valeur, par exemple :
Le processus de mise en œuvre de cette opération est le suivant : créez d'abord une nouvelle chaîne pouvant contenir 10 caractères, puis remplissez cette chaîne avec "Java" et "Script", et la dernière étape consiste à détruire la chaîne d'origine "Java" et "Script", car ces deux chaînes ne sont plus utiles. Cependant, dans les navigateurs de versions inférieures (tels que IE6), la vitesse de concaténation des chaînes est un processus très consommateur de performances.
Cela me rappelle Java. Le mécanisme de chaîne en Java est similaire à js (c'est-à-dire qu'il ne peut pas être modifié une fois créé, et la valeur d'origine ne peut être détruite que si vous souhaitez la modifier). a un StringBuffer pour résoudre le problème de l'incapacité des chaînes. Le problème est qu'il n'existe pas de méthode similaire dans js. Mais nous pouvons simuler ce mécanisme de mise en mémoire tampon. Le principe est d'utiliser des tableaux pour l'épissage. Le code source est le suivant :
/*Test*/
var buffer = new StringBuffer();
buffer.append("Bonjour").append("javascript");
var result = buffer.toString();
alerte(résultat);
ps : L'adresse essentielle est la suivante : https://gist.github.com/hehongwei44/fe71f10e4d2d9295aeab
Nous avons simulé le mécanisme, mais dans quelle mesure les performances de cette méthode sont-elles différentes de celles de l'épissage de chaînes ? Nous pouvons le tester :
var oBuffer = new StringBuffer();
d3 = nouvelle Date();
pour(var je = 0; je < 10000; je ){
oBuffer.append("text ");
>
var sResult = oBuffer.toString();
d4 = nouvelle Date();
document.write("Coût du test 2 : " (d4.getTime() - d3.getTime())/1000 "secondes");
Les résultats des tests sont les suivants : (Les résultats des tests peuvent être différents selon l'environnement) :
1. Sur la base d'une comparaison de 1000 fois, les deux exécutions sont très rapides (en gros quelques millisecondes) et la consommation de temps est similaire. La différence entre la dernière et la première ne dépassera pas 10 millisecondes.
2. Avec 10 000 fois comme base, les résultats d'exécution sont similaires à ceux ci-dessus, mais le premier a plus de frais d'appel sous IE6.
3. En prenant 100 000 fois comme base, l'épissage de chaînes prend évidemment plus de temps sous IE6. Les autres navigateurs ne sont pas très différents, et certains sont plus courts que StringBuffer.
Conclusion
1. Lorsque le nombre de mots épissés est inférieur à 1 000 fois, utilisez hardiment le premier. Généralement, nous rencontrons rarement des situations où le nombre de mots épissés est des milliers.
2. Les autres navigateurs n'ont aucun problème de performances avec l'épissage, principalement IE6. Si le nombre d'épissages est de plusieurs dizaines de milliers ou centaines de milliers, il est recommandé d'utiliser la simulation StringBuffer pour IE6 uniquement.