Recently, in the study of "Javascript Advanced Programming", there is a description of the characteristics of strings. The original text is roughly as follows: Strings in ECMAScript are immutable, that is, once strings are created, their values cannot be changed. To change the saved string of a variable, first destroy the original string, and then fill the variable with another string containing the new value, for example:
The code copy is as follows:
var lang = "Java";
lang = lang + "Script";
The process of implementing this operation is as follows: first create a new string that can hold 10 characters, and then fill it with "Java" and "Script" in this string. The last step is to destroy the original strings "Java" and "Script", because these two strings are useless. However, in lower versions of browsers (such as IE6), string splicing speed is a performance-consuming process.
From this I think of Java. The string mechanism in Java is similar to js (that is, it cannot be changed after creation, and to change it can only destroy the original value), but Java has a StringBuffer that solves the problem of string immutability, and js does not have a similar method. But we can simulate this buffering mechanism. The principle is to use arrays for splicing, the source code is as follows:
The code copy is as follows:
function StringBuffer() {
this.__strings__ = new Array();
}
StringBuffer.prototype.append = function (str) {
this.__strings__.push(str);
return this; //Convenient chain operation
}
StringBuffer.prototype.toString = function () {
return this.__strings__.join("");
}
/*test*/
var buffer = new StringBuffer();
buffer.append("Hello").append("javascript");
var result = buffer.toString();
alert(result);
ps:gist address is as follows: https://gist.github.com/hehongwei44/fe71f10e4d2d9295aeab
We have simulated the mechanism, but there is a difference in performance between this method and string splicing. We can test it, and the test code is as follows:
The code copy is as follows:
var d1 = new Date();
var str = "";
for(var i = 0; i < 10000; i++){
str += "text ";
}
var d2 = new Date();
document.write("Test one cost: " + (d2.getTime() - d1.getTime())/1000 + "seconds"+"<br/>");
var oBuffer = new StringBuffer();
d3 = new Date();
for(var i = 0; i < 10000; i++){
oBuffer.append("text ");
}
var sResult = oBuffer.toString();
d4 = new Date();
document.write("Test two costs: " + (d4.getTime() - d3.getTime())/1000 + "seconds");
The test results are as follows: (The test results may be different in different environments):
1. When comparing 1000 times as the base, the execution of both is very fast (basic milliseconds) and takes about the same time. The latter difference between the former will not exceed 10 milliseconds.
2. With 10,000 times as the base, the execution result is similar to the above, but the former has more phone bills under IE6.
3. With 100,000 times as the base, string splicing in IE6 obviously takes more time, and other browsers are not much different, and some are shorter than StringBuffer.
in conclusion
1. When the number of splicing words is less than 1,000 times, boldly use the former, and we rarely encounter thousands of splicing times.
2. Other browsers have no performance problems with splicing, mainly IE6. If splicing times cost tens of thousands or hundreds of thousands, it is recommended to use StringBuffer to simulate IE6 alone.