My personal experience on JS efficiency (8-15 updates). First of all, I would like to thank CSDN hbhbhbhbhb1021 for your reminder and cuixiping. I will take the time to test the speed of the proprietary IE method such as insertAdjacentHTML to see if it is suitable for a large amount of data in IE, without the speed of innerHTML.
The main test here is not the speed at which data is generated, but the matching speed.For example
Matching speed here
I tested 10000 pieces of data, valid data:-pieces, output complicated HTML, the speed is around ms, the method is regular Match (with loops)
You want to paste your test data.
The results of testing the speed of innerHTML and insertAdjacentHTML are no more than 20 ms (average speed). In IE, the speed of insertAdjacentHTML is still very fast, and it is not worth the candle in Mozilla.
Click here to perform a simple matching test.
Click here to test the speed of innerHTML and insertAdjacentHTML, which is compatible with Mozilla's
In this article, I also deleted, deleted, and reduced the statements, so the statements were not fluent, and my friends had a hard time reading them.
This article is mainly due to a friend who used my original autocomplete JS control. When there is a large amount of data, the efficiency will be extremely slow. I have made some tests and some experience during this period. I would like to share with you, if there is something wrong, please also point out.
After testing, we will find the following situations or conclusions. If your test results are inconsistent with mine, please explain the reasons for mutual learning.
1) when a large HTML string is given to obj. innerHTML, the problem may occur. That is to say, when a large string is given an innerHTML Element, this process may be intolerable. (In fact, this is not a JS error, but it is true that the String data volume is too large)
2) The String concatenation method can improve the efficiency. When the string is large, 2) the problem still occurs. If it exceeds a certain number, the speed will obviously slow down.
3) The regular expression matching method is more efficient than the normal Traversal method.
4) During execution, it takes more time to bind events. In the case of 100 pieces of data, the test is about 30 times that of matching and generating HTML data. That is to say, the total cost of generating data is 3000 ms, and binding events requires ms.
5) overall. IE is slower than Mozilla (I used Firefox1.5 for testing ).
6) when there is a large amount of data, do not use DOM to generate elements.
7) Non-JS built-in methods may lead to a lot of time-consuming and repetitive work. We recommend that you use the built-in method whenever possible.
Summary:
1. Give the string to innerHTML.
II. the time it takes to bind events cyclically.
3. It takes time to generate the required DIV.
4. Different browser problems.
The following remedies:
Question 1
We can do nothing else, with only as few HTML strings as possible, such as the most basic DIV, which can be written in this way.
You can also write it like this.
The second is faster than the first one. If not, check whether this method is suitable for you.
When I was working on a program, I suddenly remembered the PK tree on 51js, a tree written by a moderator, a node of 1 million, and dynamic loading. It takes less than 1 second. There is no doubt that it is a coincidence, because as long as only the html of the tree is a large number. The special feature of this tree is that when a tree is generated, instead of generating innerHTML for one million nodes at a time, it only generates nodes within the angle of view. When the scroll bar rolls down, to generate a tree node dynamically. At least I think this method is very open-minded and valuable.
We know that data in the mySQL database can be retrieved in this way. SELECT * FROM table limit 0,100, meaning only 0-data records in the database are obtained. Some friends may also think that in JS, we can use this method to retrieve data and regard an array as a table. It's just a data table, not a two-dimensional table.
With this, we can take out valid data values first.
Think about it. Assume that we take an array with a subscript of 10000 and set the HTML length of 20 (very small"
Item
).
Matching data is known: There are 3000 data records
The number of input bytes is 3000 (asc code), that is, 3000*20 = 60000 bytes.
With the limit method, the output is 10*20 = 200 bytes.
Very obvious difference!
Then we can solve the problem step by step, that is, when the scroll bar appears, or press down (direction key) to dynamically generate innerHTML.
Update 8-13: I tested the speed of limit written by myself, and the built-in Array. slice is faster than slice, and sometimes it is faster than slice.
Array. prototype. limit = function (l, h ){
Var _ a = this; var ret = [];
L = l <0? 0: l; h = h> _ a. length? _ A. length: h;
For (var I = 0; I <_ a. length; I ++ ){
If (I> = l & I <= h) ret [ret. length] = _ a [I];
If (I> h) break;
}; Return ret;
}
If you are interested, you can test it by yourself and paste the data to see which efficiency is better.
Question 2,
Why do we need to bind events cyclically?
Because of Problem 1.
Assume that
1)
Never-online
You can also write
2)
Never-online
Document. getElementById ("container"). childNodes [0]. onclick = function () {handlerClick ()};
In this way, you can save some strings to save string resources. However, we need to traverse the sub-elements of the iner, so it will take time. Is it the first method or the second one? I suggest using the first type, but it is best to minimize the string, such:
Never-online
In the case of a large amount of data, the fewer characters, the better, although the Code is not very beautiful.
Question 3,
When generating a DIV, we can generate
Var p = document. createElement ("DIV ");
P. onclick = function (){};
// TODO
You can also use a string
Var sHtml ="
Val
";
When the number of hours, the first speed will be faster than the second. But when it reaches an order of magnitude, the second is obviously faster than the first one. In general, the second type is better. Because the second type can be more flexible, such as using join and regular matching.
Question 4,
This issue cannot be ignored. Each browser has different features and different execution speeds. I personally think this is the same as the Optimization Efficiency on JS.
Use the built-in method of the browser as much as possible, so that efficiency can be improved in most cases.
So how can we improve the efficiency of scripts?
1) match with match, an aCache array. Loop match. length and give it to aCache, then join (""), and then to innerHTML (this method still requires loops and an additional array for temporary data storage)
2) No Loops are required, but a specified string must be generated when data is generated. (This method also requires additional space for temporary data)
3) it is better to make multiple judgments and repeat them without repeating them. E. g:
The value obtained for the first time in the input control is: 1, and the value pressed for the second time is 12.
If you make a judgment, you can store a value for the event, that is, the value of the previous press. The value 1 above. There is no return for the second press, that is, adding a character 2 in the previous value, then we will match the data matched in the previous 1. This greatly reduces the number of cycles.
4) use the limit written in question 1 to Dynamically Retrieve data. These can solve the problem of HTML strings being too large, but if this method is not properly controlled, it will be okay.
5) Use the range technique to add HTMLStrThat is to say, when an HTML string is too large, use innerHTML + = anotherHTMLStr. This method also slows down the speed. in IE, we can use obj. insertAdjacentHTML ("beforeEnd", anotherHTMLStr) to insert HTML. This method has been tested and is relatively stable. Using limit with insertAdjacentHTML will make the inserted HTML code more stable. in Mozilla, the range technique should be used to achieve this purpose, as follows: if (browser. isMozilla ){
HTMLElement. prototype. insertAdjacentHTML = function (sWhere, sHTML ){
Var df; var r = this. ownerDocument. createRange ();
Switch (String (sWhere). toLowerCase ()){
Case "beforebegin ":
R. setStartBefore (this );
Df = r. createContextualFragment (sHTML );
This. parentNode. insertBefore (df, this );
Break;
Case "afterbegin ":
R. selectNodeContents (this );
R. collapse (true );
Df = r. createContextualFragment (sHTML );
This. insertBefore (df, this. firstChild );
Break;
Case "beforeend ":
R. selectNodeContents (this );
R. collapse (false );
Df = r. createContextualFragment (sHTML );
This. appendChild (df );
Break;
Case "afterend ":
R. setStartAfter (this );
Df = r. createContextualFragment (sHTML );
This. parentNode. insertBefore (df, this. nextSibling );
Break;
}
};
} Postscript: there is no complete solution to the efficiency issue, which is determined only in practice. Therefore, the above method is for your reference only. If you have some good methods, you can write your experience in the comments for communication.
