Personal experience on JS efficiency (updated on 8-15), adding range skills_javascript skills

首先，要谢谢CSDN hbhbhbhbhb1021(天外水火(我要多努力))和cuixiping(无心)的提醒。我会抽空把IE专有的方法如：insertAdjacentHTML的速度也给测出来看看是否合适大量数据时IE下，不用innerHTML的速度。
这里的主要测试不是指生成数据时的速度，指的是匹配速度 ，例如
我这里的匹配速度
我测的10000条数据，有效数据为1000-1100条，输出复杂的HTML，速度为360ms左右，方法为 正则匹配Match（有循环）
希望贴出您的测试数据。
行innerHTML和insertAdjacentHTML速度的测试，比均结果相差不会大于20ms（平均速度），在IE中insertAdjacentHTML速度还是很快的，在Mozilla下是得不偿失的。

可以点击这里进行简单的匹配测试
点击这里进行innerHTML和insertAdjacentHTML速度的测试，可以兼容Mozilla的

写这篇文章，其间我也是删删减减的，所以语句也不怎么通顺，看的朋友也就辛苦了一些了。

本文主要是出于有朋友使用我原来写的autocomplete的JS控件。当数据量大的时候，会出现效率极其慢的情况，我在这段时间做出的一些测试也及一些经验，与大家分享，如果有错的地方，还请指出。

经过测试，我们会发现如下的情况或者说的结论，如果您的测试结果与我的不符，请说明原因，以便相互学习。

1）当一个较大的HTML字符串给到obj.innerHTML时会出现麻烦。也就是说当一个较大的字符串在赋予一个Element的innerHTML时，这个过程将可能是我们无法容忍的。（而事实上这并非JS的错，而确实是String数据量太多）
2）用拼合字符串的方法可以使效率提高，在字符串较大时，2）的情况仍然出现。超过一定的数量，速度会明显慢下来。
3）正则匹配的方法会比平常遍历的方法要高效一些。
4）在执行过程中，绑定事件的时间会花费更多一些。测试在1w条数据情况下，大约是匹配以及生成HTML数据的30倍，也就是说生成数据总花费100ms，而绑定事件则需要3000ms。
5）总体来说。IE的速度要比Mozilla要慢（我用的是Firefox1.5做的测试）。
6）大数据量时，不要用DOM生成Element。
7）非JS内置方法，也许会引发很多时间过多重复的劳动而且可能事得其反。建议尽可能利会内置方法。
总结问题：
一、在把字符串给到innerHTML上。
二、循环绑定事件所花费时间。
三、生成我们需要的DIV所花时间。
四、不同的浏览器问题。

下面对症下药：

问题一

我们可以做的没有其它的，只有尽可能少的HTML字符串，比如最基本的一个DIV，可以这样写

也可以这样写，第二种就比第一种速度明显要快的。如果还不行的话，请看下面这个方法对你是否合适

在做程序的时候突然想起来51js上PK tree，一位版主所写的一棵树，1百万的一个节点，动态载入。只需要不到1秒。毫无疑问，肯定是取巧了，因为只要只生tree的html就是一个很大的数量。这个树的特别的地方就是生成树时，并非把1百万的节点都一次生成innerHTML，而是只生成在视角范围内的节点，当滚动条向下滚的时候，才动态的再生成树节点。这个方法至少我觉得思想很开阔，很有价值。

我们所知道，mySQL数据库里取数据可以这么取。SELECT * FROM table limit 0,100，意思是只取数据库中的0-100条数据。说到这里可能有些朋友也想到了，在JS中，我们可以利用这个方法来取数据，将一个数组看作是一个表。只是单纯的数据表，非二维表。如图

利用这一些，我们可以把数据有效的值先取出来。如图：

想想看。假如我们取一个数组，下标为10000，设生成一个autocomplete的节点HTML长度20（已经非常小了"）。
匹配数据已知：有3000条数据
输节字节数为：3000(asc码)也就是3000*20=60000字节
而用limit方法，输出为：10*20=200字节。
很明显的差距！
之后我们便可以分步求解，即当滚动条出现，或者按下down（方向键）再动态的生成innerHTML。
8-13更新：测了一下，用自己写的limit的速度，和自带的Array.slice的速度比了一下，速度差不多，而且有的时候还比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;
}
有兴趣的朋友也可以自己测一下，贴出数据，看看哪个效率更好。

问题二、
为什么我们还要循环来绑定事件呢？
还是由于问题一。
假设这样写
1)

还可以这样写
2)

document.getElementById("container").childNodes[0].onclick=function(){handlerClick()};
这样也可以省掉一些字符串，从而节省字符串资源。但又需要把container的子元素再遍历，所以也会花费时间，用第一种方法还是第二种？我建议还是用第一种，但最好把字符串减到最低，如：

大数据量情况下，还是越少字符越好，虽然代码不怎么美观。

问题三、
生成DIV时我们可以这样生成
var div = document.createElement("DIV");
div.onclick=function(){};
//TODO
也可以这样用字符串
var sHtml = "";
当数量小时，第一种速度会比第二种快。但当达到一个数量级时，第二种要明显比第一种快。总体来说第二种较好。因为第二种还可以更灵活，比如利用join，还有正则匹配。

问题四、
这个问题也不容忽视的。每个browser有不同的特点，速度执行也有不同，我个人觉得，这点和JS上优化效率上是一样的。
尽可能的利用浏览器本身的内置方法，这样大多数情况下也可以把效率提高。

那么如何能够把脚本的效率提高起来呢？
1）用match匹配，一个aCache数组。循环match.length，并给aCache，之后用join("")，再给到innerHTML（此方法仍然需要循环，而且需额外的一个数组做临时数据存储）
2）无需循环，但必须在生成数据时也额外生成指定字符串。（此方法也需要额外的空间做临时数据）如图：

3) It is better to judge multiple times than to re-match again. e.g:
The first value obtained in the input control is: 1, and the value obtained the second time is 12
If judgment is made, a value can be stored in the event, which is the value of the previous press. . Like the value 1 above. There is no backspace when pressed for the second time, that is, adding a character 2 to the previous value, then we will match the data matched in the previous 1. This can greatly reduce the number of cycles.
4) Use the limit written in question 1 to dynamically retrieve the data. These can very well solve the problem of excessively large HTML strings, but if this method is not properly controlled, it will be counterproductive.
5) Use the range technique to add HTMLStr, that is to say, when an HTML string is too large, use innerHTML =anotherHTMLStr. This method will also make the speed too slow. In IE , we can use obj.insertAdjacentHTML("beforeEnd", anotherHTMLStr) to insert HTML. This method has been tested and is relatively stable. Using limit plus insertAdjacentHTML will make the inserted HTML code more stable. In Mozilla, you need to use range techniques to achieve this goal, as follows: Postscript: There is no complete solution to the efficiency problem; In practice, it depends on the needs. Therefore, the above methods are for your reference only. If you also have some good methods, you can write down your experience in the comments for communication.