Recientemente, en el estudio de la "programación avanzada de JavaScript", hay una descripción de las características de las cuerdas. El texto original es más o menos como sigue: las cadenas en Ecmascript son inmutables, es decir, una vez que se crean las cadenas, sus valores no se pueden cambiar. Para cambiar la cadena guardada de una variable, primero destruya la cadena original y luego llene la variable con otra cadena que contiene el nuevo valor, por ejemplo:
La copia del código es la siguiente:
var lang = "java";
lang = lang + "script";
El proceso de implementación de esta operación es el siguiente: primero cree una nueva cadena que pueda contener 10 caracteres y luego llenarla con "Java" y "Script" en esta cadena. El último paso es destruir las cadenas originales "Java" y "Script", porque estas dos cuerdas son inútiles. Sin embargo, en versiones más bajas de navegadores (como IE6), la velocidad de empalme de cadena es un proceso que consume rendimiento.
De esto pienso en Java. El mecanismo de cadena en Java es similar a JS (es decir, no se puede cambiar después de la creación, y cambiarlo solo puede destruir el valor original), pero Java tiene un StringBuffer que resuelve el problema de la inmutabilidad de la cadena, y JS no tiene un método similar. Pero podemos simular este mecanismo de amortiguación. El principio es usar matrices para empalme, el código fuente es el siguiente:
La copia del código es la siguiente:
función stringBuffer () {
this .__ Strings__ = new Array ();
}
Stringbuffer.prototype.append = function (str) {
this .__ Strings __. Push (str);
devolver esto; // Operación de cadena conveniente
}
StringBuffer.Prototype.ToString = function () {
devuelve esto .__ cadenas __. unir ("");
}
/*prueba*/
var buffer = new StringBuffer ();
buffer.append ("hola"). append ("javaScript");
resultado var = buffer.ToString ();
alerta (resultado);
PD: la dirección GIST es la siguiente: https://gist.github.com/hehongwei44/fe71f10e4d2d9295aeb
Hemos simulado el mecanismo, pero hay una diferencia en el rendimiento entre este método y el empalme de cadenas. Podemos probarlo, y el código de prueba es el siguiente:
La copia del código es la siguiente:
var d1 = nueva fecha ();
var str = "";
para (var i = 0; i <10000; i ++) {
str += "texto";
}
var d2 = nueva fecha ();
document.write ("Test One Costo:" + (d2.gettime () - d1.gettime ())/1000 + "segundos" + "<br/>");
var obUffer = new StringBuffer ();
d3 = nueva fecha ();
para (var i = 0; i <10000; i ++) {
obuffer.append ("texto");
}
var sResult = obuffer.ToString ();
d4 = nueva fecha ();
document.write ("Prueba dos costos:" + (d4.gettime () - d3.gettime ())/1000 + "segundos");
Los resultados de la prueba son los siguientes: (los resultados de la prueba pueden ser diferentes en diferentes entornos):
1. Al comparar 1000 veces como la base, la ejecución de ambos es muy rápida (milisegundos básicos) y lleva aproximadamente el mismo tiempo. La última diferencia entre el primero no excederá los 10 milisegundos.
2. Con 10,000 veces como base, el resultado de la ejecución es similar al anterior, pero el primero tiene más facturas telefónicas bajo IE6.
3. Con 100,000 veces como la base, el empalme en IE6 obviamente lleva más tiempo, y otros navegadores no son muy diferentes, y algunos son más cortos que StringBuffer.
en conclusión
1. Cuando el número de palabras de empalme es menos de 1,000 veces, usamos audazmente el primero, y rara vez encontramos miles de tiempos de empalme.
2. Otros navegadores no tienen problemas de rendimiento con el empalme, principalmente IE6. Si los tiempos de empalme cuestan decenas de miles o cientos de miles, se recomienda usar StringBuffer para simular IE6 solo.