JavaScript极速狂飙:大容量字符型数组的快速检索


    JavaScript 在大容量数组的循环方面效率不尽人意,我曾经做过一个比对,与VBS的数组相比较,VBS的数组循环速度大致比JS要快一个数量级(http://community.csdn.net/Expert/TopicView.asp?id=4313487)。JS数组在一般的编程当中我们也不会太去注意它的效率问题:才几十个元素的数组效率即使差点你也看不出来,但节点量一大,比如几千、比如上万个节点量的数组循环,那效率问题就成了首要考虑解决的问题了。大容量数组的检索大致有以下几个应用:select做combo box时的快速匹配、树的查询、表格table排序或者检索等。

    下面我来做一个测试,首先我先创建一个大容量的数组:

    <SCRIPT LANGUAGE="JavaScript">
    var n = 100000; //数组的最大容量
    var a = new Array();
    for(var i=0; i<n; i++)
    {
      a[i] = Math.random() +"";
    }
    </SCRIPT>

    这样我就创建了一个长度为 100000 的字符型数组,然后我再检索字符串以 0.9999 开始的字符串,并存入另一个数组中。

    <SCRIPT LANGUAGE="JavaScript">
    var n = 100000; //数组的最大容量
    var a = new Array();
    for(var i=0; i<n; i++)
    {
      a[i] = Math.random() +"";
    }

    var begin = new Date().getTime();
    var b = new Array();
    for(var i=0; i<n; i++)
    {
      if(a[i].indexOf("0.9999")==0)
      {
        b[b.length] = a[i];
      }
    }
    document.write("数组长度:"+ n);
    document.write("<br>传统循环法耗时 "+ (new Date().getTime() - begin)
    +" 毫秒!检索的结果:<strong title='"+ b.join("&#13;")
    +"'>检索到 "+ b.length +" 个记录!</strong>");
    </SCRIPT>

    这步操作我这里耗时都在2800毫秒左右,说明一下,这里的循环非常简单,只有一个 if 判断和一个赋值操作,非常简单,若这里的判断稍微复杂一些那它的耗时将是数量级的增大。那么对于这种问题有什么好的优化方案吗?答案当然是有的,否则我开这个贴子说的全是费话了。但是对于这个问题不能再使用我们的传统思维来优化,因为在传统的思维里已经找不出再好的写法了。

    解决的方案就是:先把数组join()成一个大字符串,然后用正则表达式对这个大字符串进行匹配检索。这个方法算是我的个人独创吧,在我写树的过程中想出的歪招,不过效率真的不赖。关于join()的效率我已经开贴讨论过了(http://blog.csdn.net/meizz/archive/2005/12/14/552260.aspx  JavaScript极速狂飙:组合拼接字符串的效率)。这个优化方案需要有一定的正则表达式功底。

<input id="count" value="50000" size="7" maxlength="6">
<input type="button" value="数组初始华" onclick="txt.innerHTML = array_init()"><br>
<input type="button" value="传统循环" onclick="txt.innerHTML += method_for()">
<input type="button" value="正则匹配" onclick="txt.innerHTML += method_regexp()">
<div id="txt"></div>

<SCRIPT LANGUAGE="JavaScript">
var txt = document.getElementById("txt");
var a = new Array();

function array_init()
{
    var n = parseInt(document.getElementById("count").value);
    a.length = 0;
    for(var i=0; i<n; i++)
    {
      a[i] = Math.random() +"";
    }
    return "数组长度:"+ n;
}

function method_for()
{
    var n = a.length;
    var begin = new Date().getTime();
    var b = new Array();
    for(var i=0; i<n; i++)
    {
      if(a[i].indexOf("0.9999")==0)
      {
        b[b.length] = a[i];
      }
    }
    return ("<br>传统循环法耗时 "+ (new Date().getTime() - begin)
    +" 毫秒!检索的结果:<strong title='"+ b.join("&#13;")
    +"'>检索到 "+ b.length +" 个记录!</strong>");
}

function method_regexp()
{
    var begin = new Date().getTime();
    var b = new Array();
    var s = a.join("/x0f");
    var r = new RegExp().compile("0//.9999//d+", "g");
    b = s.match(r);   s = "";
    return ("<br>正则匹配法耗时 "+ (new Date().getTime() - begin)
    +" 毫秒!检索的结果:<strong title='"+ b.join("&#13;")
    +"'>检索到 "+ b.length +" 个记录!</strong>");
}
</SCRIPT>

    大家可以测试一下,上面两种方法之间的效率到底相差多少!代码是死的,人是活的,换一种思维换一种模式,效率将大相径庭。

    这一招我是花了好多脑筋才想出来的招,真有点舍不得放出来,现在就拿它恭贺大家2006新的一年的开始吧。

阅读更多

JavaScript极速狂飙大容量字符数组快速检索_meizz

01-04

rn JavaScript 在大容量数组的循环方面效率不尽人意,我曾经做过一个比对,与VBS的数组相比较,VBS的数组循环速度大致比JS要快一个数量级(http://community.csdn.net/Expert/TopicView.asp?id=4313487)。JS数组在一般的编程当中我们也不会太去注意它的效率问题:才几十个元素的数组效率即使差点你也看不出来,但节点量一大,比如几千、比如上万个节点量的数组循环,那效率问题就成了首要考虑解决的问题了。大容量数组的检索大致有以下几个应用:select做combo box时的快速匹配、树的查询、表格table排序或者检索等。rnrn 下面我来做一个测试,首先我先创建一个大容量的数组:rnrn rnrn 这样我就创建了一个长度为 100000 的字符型数组,然后我再检索字符串以 0.9999 开始的字符串,并存入另一个数组中。rnrn rnrn 这步操作我这里耗时都在2800毫秒左右,说明一下,这里的循环非常简单,只有一个 if 判断和一个赋值操作,非常简单,若这里的判断稍微复杂一些那它的耗时将是数量级的增大。那么对于这种问题有什么好的优化方案吗?答案当然是有的,否则我开这个贴子说的全是费话了。但是对于这个问题不能再使用我们的传统思维来优化,因为在传统的思维里已经找不出再好的写法了。rnrn 解决的方案就是:先把数组join()成一个大字符串,然后用正则表达式对这个大字符串进行匹配检索。这个方法算是我的个人独创吧,在我写树的过程中想出的歪招,不过效率真的不赖。关于join()的效率我已经开贴讨论过了(http://blog.csdn.net/meizz/archive/2005/12/14/552260.aspx JavaScript极速狂飙:组合拼接字符串的效率)。这个优化方案需要有一定的正则表达式功底。rnrn rnrn 大家可以测试一下,上面两种方法之间的效率到底相差多少!代码是死的,人是活的,换一种思维换一种模式,效率将大相径庭。rnrn 这一招我是花了好多脑筋才想出来的招,真有点舍不得放出来,现在就拿它恭贺大家2006新的一年的开始吧。

JavaScript极速狂飙:组合拼接字符串的效率(meizz)

12-14

rn 在脚本开发过程中,经常会按照某个规则,组合拼接出一个大字符串进行输出。比如写脚本控件时控制整个控件的外观的HTML标签输出,比如AJAX里得到服务器端的回传值后动态分析创建HTML标签时,不过这里我就不讨论拼接字符串的具体应用了,我只是想在这里讨论一下拼接的效率。rnrn 字符串的拼接在我们写代码的时候都是用“+=”这个运算符,s += String; 这是我们最为熟知的写法,不知道大家有没有注意过没有,在组合的字符串容量有几十K甚至几百K的时候,脚本执行起来很慢,CPU使用率狂高,例如:rnrn var str = "01234567891123456789212345678931234567894123456789";rn str+= "51234567896123456789712345678981234567899123456789\n";rn var result = "";rn for(var i=0; i<2000; i++) result += str;rnrn 就这么一步操作,产生的结果字符串是200K,耗时是1.1秒(这个与电脑配置有关),CPU的峰值100%。(为了更直观地看到效果,我多做了些循环)。可想而知就这么一步操作就消耗了我一秒多的时间,再加上其它的代码的时间消耗,那整个脚本块的执行时间就难以忍受了。那有没有优化的方案呢?还有其它的方法吗?答案当然是有的,否则我写这篇文章就是废话。rnrn 更快的方式就是使用数组,在循环拼接的时候不是相接拼接到某个字符串里去,而是把字符串放到一个数组里,最后用数组.join("") 得到结果字符串,代码示例:rnrn var str = "01234567891123456789212345678931234567894123456789";rn str+= "51234567896123456789712345678981234567899123456789\n";rn var result = "", a = new Array();rn for(var i=0; i<2000; i++) a[i] = str;rn result = a.join(""); a = null;rnrn 大家可以测试测试,组合出一个相同大小的字符串所消耗的时间,我这里测试出来的结果是:<15毫秒,请注意,它的单位是毫秒,也就是说组合出这么一个200K的字符串,两种模式的时间消耗是差不多两个数量级。这意味着什么?意味着后者已经工作结束吃完中饭回来,前者还在做着苦力。我写一个测试页面,大家可以把下面这些代码拷贝下来另存为一个HTM文件在网页里打开自己来测试一下两者之间的效率差,反正我测试的是前者要半分钟才能完成的事,后者0.07秒就搞定了(循环10000次)。rnrnrn字符串拼接次数rnrn rn rn rnrn

JavaScript极速狂飙:CSS样式表的渲染效率

12-09

rn 我的MzTreeView1.0树控件发布至今,得到了不少意见反馈,很多网友给了我很多的中肯的建议,也指出了这个控件里的诸多BUG和不足之处,所以我准备写一个新版本的树,将大家的建议都整合进来实现。这几天我就一直在写新版的树,树控件最重要的是效率,特别是大节点量的时候,效率稍微差点的模式就会拖垮浏览器,所以新版的树我首要的还是提高效率,比如增加异步数据加载的支持等,另外我还有一个设想,就是树的树型结构竖线用样式表(背景图)来实现,样式表背景图片只需要加载一次,而现在这个模式(用多个)图片虽然有缓存机制,但还是有可以每张小图片都请求一次服务器的,所以我想用样式表来实现有多么的好呀,代码又精简,结构又清晰,效果又酷,但是结果我将近一个星期的测试,我这种设想彻底失败,原因就是样式表的渲染效率太差。新的构想没能实现,心情有些沮丧,但我想也应该让大家分享一下这个测试成果。rnrn 这里我再解释一下树型里的竖线,树的左边都有 ┌ ├ └ │ 这些竖线图表示树层次,我的1.0版里是用一张张的小图片堆积起来的,而这种使用样式表的是用 这种代码来实现的,样式表负责填充背景图。rnrn #mtvroot div tdwidth:20px;height:20px;rn #mtvroot .l0background:url(line0.gif) no-repeat centerrn #mtvroot .l1background:url(line1.gif) no-repeat centerrn #mtvroot .l2background:url(line2.gif) no-repeat centerrn #mtvroot .l3background:url(line3.gif) no-repeat centerrn #mtvroot .l4background:url(line4.gif) no-repeat centerrn #mtvroot .llbackground:url(line5.gif) no-repeat centerrn #mtvroot .pm0background:url(plus0.gif) no-repeat centerrn #mtvroot .pm1background:url(plus1.gif) no-repeat centerrn #mtvroot .pm2background:url(plus2.gif) no-repeat centerrn #mtvroot .pm3background:url(plus3.gif) no-repeat centerrn #mtvroot .expand .pm0background:url(minus0.gif) no-repeat centerrn #mtvroot .expand .pm1background:url(minus1.gif) no-repeat centerrn #mtvroot .expand .pm2background:url(minus2.gif) no-repeat centerrn #mtvroot .expand .pm3background:url(minus3.gif) no-repeat centerrnrn 上面这段CSS是我在脚本里动态生成的一段样式的片段,我把它贴上来,有助于后面的讲解。运用样式表之后,果真精简了许多,每个节点的生成也够快,但我发现,当我的树节点量达到,比如说300-500个节点之后,节点生成的效率没有影响什么,但每个节点的展开/收缩很慢很慢,需要几秒钟以上甚至10秒,且这个期间的CPU占用率是100%。说明一下,树型的展开/收缩是设置父节点的 style.display = none|block 来实现的。我的电脑配置是:AMD2800+ 1GDDR400内存,配置不太差的。rnrn 我首先的反应是:是不是用了太多的 影响了效率?因为我每一个节点都用了一个 ,但是我把 、等,效率没有什么改善,说明这个CPU占用率100%的问题不是HTML标签的问题,那么剩下来的问题就是这里使用了样式表。rnrn 以一个500节点的量来说吧,1.0里左边大概要堆积2000个左右的小图片。这种情况在浏览器端设置本地不缓存的时候会存在很大的问题,要加载这些多的小图片需要消耗不少的时间和服务器资源,所以我才会有这种新的用样式表来解决的想法,现在换成样式表法,也就是大概有2000个地方需要用样式表来渲染出背景图。我测试了各种情况,再对比1.0版的代码得出的结论是:CPU的点用率如此之高,唯一的原因也就只有这种渲染的耗时了。验证也非常简单,我把上面的样式表的左边 #mtvroot 这部分去掉,也就是去掉样式表的依托关系,测试的结果发现效率改善了很多,但耗时依然是可观的,有3-5秒之多。rnrn 另外我换了不同的浏览器,测试的结果也不太一样,在IE里最为恶心,比如说我在某个节点有500子节点,我将它收起(CPU100%,等待3-5秒),也就是display="none",这时候若我去收起这个节点的父节点(这个节点没有其它的同级节点,即它的父节点只有它这么一个子节点),照理说只有一个节点,收起应该是即时的事,但结果不然,结果又是3-5秒的CPU100%,这个让我狂郁闷,也就是说即使HTML对象被display="none"隐藏掉了,但是对它的父级进行任何操作的时候,IE会对这些被隐藏的对象用样式表重新渲染一遍,真是搞不懂IE的开发者当初是怎么想的。rnrn 我又到FIREFOX里测试了一下,在收起的时候(display=none)是瞬间的,可以肯定,FF对待被隐藏的对象不会再消耗精力。当然展开的时候所有的浏览器都一样:3-5秒的CPU100%,不过FF稍微要快些。rnrn 通过上面的这些现象我得出这么一个结论:样式表在动态渲染的时候效率并不高;在父容器发现状态变化的时候会引起它的所以子孙对象的样式表重新渲染;FireFox 对待被display=none隐藏的对象不会重新渲染而IE会。rnrn 那么这种样式表的渲染效率问题以前为什么一直没有被发现呢?嘿嘿,大家做网页的时候难得会做到这种极端的时候,一个页面里有几千个需要样式表渲染背景图。通常也就几个地方或者几十个地方了,所以感觉不出来渲染的效率,也感觉不出这方面在不同的浏览器之间的差别。但是在做树这些的控件的时候必定会碰到各种极端的问题,比如大数据量的数组,生成的HTML对象的多少等等,象这种渲染的效率差别也只是我在写JS脚本时碰到的问题之一而已。今天我把这个测试结果共享出来是希望对大家以后写程序的时候有所借荐,在做设计的时候有所考虑。rnrn 最后多谢大家对我写的控件的肯定与支持,谢谢了!rn meizz(梅花雪) 换成了

没有更多推荐了,返回首页