operamasks-ui和其它js框架性能对比

Advertisement

一、前言

前段时间我们团队推出了operamasks-ui ,得到了业界的一些关注,首先谢谢大家的关注,你们的关注就是我们团队的动力。

在推出一段时间之后也得到了一些反馈,有组件需求的反馈,有组件bug的反馈,还有性能方面的一些反馈,希望我们能给出一个性能对比报告,和各个其它js框架做一个横向的对比,让选择的时候能心中有数。

针对以上问题我们的测试人员和开发人员先选择了omTree和其它框架对比,做了一系列的测试数据,这里要声明的是我们不是要证明我们的组件有多强,只是想真实的对比一下,是好货拿出来溜溜嘛,同时也发现自己的不足,继续改进组件。

测试的前提:组件功能一致、数据和数据源一致。

二、名词解释

Render Time :用户在页面上看到第一个内容的时间。当开始渲染时用户是可以在浏览器中看见内容的,而有内容的时候 document.body.offsetHeight 应该是大于 0 的,因此根据这一特点使用 timer 来检查。(网上资料显示 FireFox 可以通过在 window 上注册“ MozAfterPaint ”事件来计算浏览器开始渲染的时间,但是实际测试时发现 FireFox7.0 根本监控不到“ MozAfterPaint ”事件,因此也根据 document.body.offsetHeight 大于 0 进行测试)

Dom Ready :文档解析完成的时间,目前对于文档解析具体包括哪些操作没有具体的答案,但文档解析至少应该包括以下操作: HTML 文档分析以及 DOM 树的创建、外链脚本的加载、外链脚本的执行以及内联脚本的执行,但不包括图片、 iframe 等其它资源的加载。

Page Load : window.onload 事件触发的时间。与 DOM Ready 时间相比, Page Load 的时间往往要更靠后一些,因为 Page Load 不仅仅是 HTML 文档解析完毕还包括了所有资源加载所需要的时间,例如图片资源的加载、 iframe 的加载等。

Show Time :组件内容展现时间,即 tree 完全展现的时间。

CPU 监控 :通过 ProcessExplorer 监控访问案例时浏览器的 CUP 占用率。

三、概述

本次测试主要是对 operamask-ui 与 easyui 、 extjsui 、 ligerui 几个产品进行前端性能对比测试,被测组件为 tree , tree 展示 10 个父节点,每个父节点下又包含 10 层子节点,在展示数据相同的情况下,比较 operamask-ui 与其他几个主流 ui 框架产品的页面加载时间、组件展示时间、 CPU 占用率等。

四、测试环境

被测对象:测试 Operamask-ui (以下检查 om-ui ), easy-ui , extjs-ui , liger-ui 的 tree 组件,分别在 firefox 、 IE 、 chrome 三种浏览器下的 render 、 domready 、 pageload 、组件内容完全展现的时间以及 CUP 利用率。

硬件配置: Pentium Dual-Core CPU E5300 @2.60GHz 2.60GHz , 3.24GB 内存


软件名称


版本


FireFox


7.0.1


IE


IE8


Chrome


17.0


ProcessExplorer


14.12

五、测试案例

1、被测组件案例

按照各个 ui 框架构造 tree 组件的方式,分别建立 tree 测试组件,测试页面中仅放置一个被测 tree , tree 展现格式为 10*10 ( 10 个父节点,每个父节点中迭代 10 层子节点)。

2、监控参数案例

(1) Render Time

var time_to_page_start = new Date()*1,bodyHeights = [];
(function(){
        function handleRender(){
            window.pmc_start_render_time = new Date()*1 - time_to_page_start;
            var h = document.createElement('h3');
            h.innerHTML='Time To Start Render:'+window.pmc_start_render_time + ' ms';
            document.body.appendChild(h);
        }
        if(document.body && document.body.offsetHeight > 0 ){
            handleRender();
            return;
        }
        if(document.body){
            bodyHeights.push(document.body.offsetHeight);
        }
        setTimeout(arguments.callee,30);
})();

说明:首先记录开始时间 time_to_page_start ,监控 document.body.offsetHeight ,当大于 0 时,表明用户能看到页面上的内容的时间,用次时间减去开始时间,则为渲染时间。

(2) Dom Ready

Dom Ready 为页面内所有 dom 节点加载完成的时间。 FireFox 中增加了一个 DOMContentLoaded 方法,该方法是在页面的 DOM 内容加载完成后即触发,而无需等待其他资源的加载。 Webkit 引擎从版本 525 ( Webkit nightly 1/2008:525+ )开始也引入了该事件, Opera 中也包含该方法。 IE 不支持该方法,但是在 IE 下, dom 的某些方法只有在 dom 解析完成后才能调用, doScroll 就是这样一种方法,因此我们通过监控 doScroll 来监控 IE 中的 Dom   Ready 时间。 Webkit 引擎低版本通过监控 readyState 来判断 dom 是否加载完毕。 JS 脚本如下:

var time_to_page_start = new Date()*1;
(function(){
    function domreadyTime(){
        window.pmc_start_render_time = new Date()*1 - time_to_page_start;
        var h = document.createElement('h3');
        h.innerHTML = 'Time To Dom Ready: ' + window.pmc_start_render_time + ' ms';
        document.body.appendChild(h);
    }
    this.conf = {enableMozDOMReady:true};
    var isReady = false;
    function doReady(){
        if( isReady ) return;
        isReady = true;
        domreadyTime();
    }
    if( /MSIE/.test(navigator.userAgent) ){
      (function(){
       if ( isReady ) return;
       try {
          document.documentElement.doScroll("left");
       } catch( error ) {
          setTimeout( arguments.callee, 0 );
          return;
       }
       doReady();
     })();
    window.attachEvent('onload',doReady);
  }
  else if (/Chrome/.test(navigator.userAgent)){
    (function(){
      if( isReady ) return;
      if (/loaded|complete/.test(document.readyState))
         doReady();
      else
         setTimeout( arguments.callee, 0 );
     })();
    window.addEventListener('load',doReady,false);
  }
  else{
     if( /Firefox/.test(navigator.userAgent) || this.conf.enableMozDOMReady)
       document.addEventListener( "DOMContentLoaded", function(){
       document.removeEventListener( "DOMContentLoaded", arguments.callee, false );
       doReady();
     }, false );
     window.addEventListener('load',doReady,false);
   }
})();

(3) Page Load

Page Load 时间指的就是 window.onload 事件触发的时间。与 DOM Ready 时间相比, Page Load 的时间往往要更靠后一些,因为 Page Load 不仅仅是 HTML 文档解析完毕还包括了所有资源加载所需要的时间,例如图片资源的加载、 iframe 的加载等。 JS 脚本如下:

 var time_to_page_start = new Date()*1;
(function(){
    function pageLoad(){
        window.pmc_start_render_time = new Date()*1 - time_to_page_start;
        var h2 = document.createElement('h3');
        h2.innerHTML = 'Time To Page Load: ' + window.pmc_start_render_time + ' ms';
        document.body.appendChild(h2);
    }
//判断浏览器是否能够识别window.addEventListener,假如可以,则执行以下代码
    if(typeof window.addEventListener!="undefined"){
        window.addEventListener('load',function(){
            window.removeEventListener('load', arguments.callee, false);
            pageLoad();
        },false);
    }
//某些浏览器无法识别window.addEventListener,只能识别document.addEventListener,因此要增加这一步判断
    else if(typeof document.addEventListener!="undefined"){
        document.addEventListener("onload",function(){
            document.removeEventListener('onload', arguments.callee, false);
            pageLoad();
        },false);
    }
    //前面两种都无法识别,则判定是否可以识别window.attachEvent  (IE)
    else if(typeof window.attachEvent!="undefined"){
        window.attachEvent("onload",function(){
            pageLoad();
        });
    }
    //前三种都无法识别,则用这最后一种:老式链式事件处理方式
    else{
        var oldfn = window.onload;
        if(typeof window.onload!="function"){
            window.onload = function(){
                pageLoad();
            }
        }
        else{
            window.onload = function(){
                oldfn();
                pageLoad();
            }
        }
})();

(4) Show Time

在我们的测试案例中,令 grid 组件读取 500 条数据, tree 组件展示 10 个节点,每个节点中包含 10 层子节点(即子节点中又包含 1 个子节点,如此循环 10 层), Show Time 用于监控组件在页面中所有数据完全展现出来的时间,通过在页面中查找 grid 组件的最后一条数据来判断该组件内容是否完全展现,通过在页面中查找 tree 组件的最后一个节点来判断该组件内容是否完全展现。 JS 脚本如下:

var time_to_page_start = new Date()*1;
/*<![CDATA[*/
(function(){
    function handleRender(){
        window.pmc_start_render_time = new Date()*1 - time_to_page_start;
        var h = document.createElement('h3');
        h.innerHTML = 'Time To Start show: ' + window.pmc_start_render_time + ' ms';
            document.body.appendChild(h);
    }
    //if($('table').find('tr').eq(500).length > 0){  //grid查找方法
    //if($('ul li').length == 110){  //easy-tree,liger-tree,om-tree查找方法
    if($('table tr').length == 111){   //extjs-tree查找方法
        handleRender();
        return;
    }
    setTimeout(arguments.callee,30);
})();

3、测试执行

为了避免各个监控参数互相影响,在被测组件的 html 文件中每次只添加一个监控参数的 js 文件,测试 CPU 时不添加监控参数的 js 文件。测试时只有一种浏览器被打开。

测试各个监控参数的操作步骤为:在浏览器中输入对应组件的 URL ,回车,记录页面中显示的时间,重复此步骤 10 次,取平均值。为了保证不受浏览器缓存的影响,保证监控参数的监听正确,每次执行完之后要清空缓存,重启浏览器。

测试 CPU 占用率的操作:打开 ProcessExplorer ,打开浏览器,输入 URL ,回车,记录回车后测试浏览器在 ProcessExplorer 中的最大值。

六、测试数据和图表

extjs-tree 在 firefox 下的特别说明:

按照我们的测试案例,设置 tree 组件为 10*10 时( 10 个父节点,每个父节点循环 10 层子节点), extjs 的 tree 组件在 FireFox7.0.1 中无法正常显示,在 IE8 和 Chrome 下可以正常显示,因此在测试 firefox 时,我们修改了 tree 组件的节点,使其展示 9*11 层。在 tree 组件为 10*10 时,节点个数为 10*10+10=110 个, tree 组件为 9*11 时,节点个数为 9*11+9=108 个,所以 extjs 的 tree 组件在 firefox 下测出的数据不是特别准,比正确的数据偏小,但是与 110 个总个数相比, 2 个节点的时间几乎可以忽略。

6.1 Render Time

单位ms



FireFox7.0.1


IE8


Chrome17.0


om- tree


166


344


108


easy- tree


229


997


251


extjs- tree


59


671


222


liger- tree


120


280


109

6.2 Dom Ready

单位ms



FireFox7.0.1


IE8


Chrome17.0


om- tree


4


31


7


easy- tree


6


31


5


extjs- tree


9


31


9


liger- tree


6


33


29

6.3 Page Load

单位ms



FireFox7.0.1


IE8


Chrome17.0


om- tree


7


32


7


easy- tree


11


31


5


extjs- tree


13


31


9


liger- tree


15


35


29

6.4 show time

单位ms



FireFox7.0.1


IE8


Chrome17.0


om- tree


84


359


99


easy- tree


179


984


263


extjs- tree


506


1145


365


liger- tree


114


281


82


6.5 CPU



FireFox7.0.1


IE8


Chrome17.0


om-tree


19.54


28.92


15.63


easy- tree


36.17


38.30


28.92


extjs- tree


50.03


52.37


38.48


liger- tree


22.32


28.92


17.31

总的来说,各个组件在ie8下面表现最差,chrome和火狐各有千秋

ext性能表现比较好,这也是我们开始没有想到的,其实ext性能不差,只是功能太多了,拖累了,在功能平等的情况下性能还是不错的。

还有就是我们测试都是本地资源,所以资源加载时间可以忽略,其实资源大小摆在那里,哪个js库大哪个小也无需我们列出来,况且功能

不同资源大小肯定不同,如果纠结于资源大小是不公平的。

Similar Posts:

  • 序列化框架的使用及性能对比Kryo、Hessian、Protostuff、java原生

    序列化 (Serialization)将对象的状态信息转换为可以存储或传输的形式的过程.在序列化期间,对象将其当前状态写入到临时或持久性存储区.以后,可以通过从存储区中读取或反序列化对象的状态,重新创建该对象. 一些开源的序列化框架可提高对象序列化以及反序列化的性能,下面先介绍在java中怎样使用序列化框架,然后对序列化框架之间的性能进行对比. 所需jar包: asm-5.0.3.jar hessian-3.0.1.jar kryo-3.0.2.jar minlog-1.3.0.jar mong

  • 现在很多js框架提倡虚拟dom,为什么虚拟dom不能在浏览器层实现

    现在很多的js框架为了提高运行性能,会提出一个叫virtual dom的概念,最有名的是facebook的react.研读了一下,virtual dom的原理基本是在dom操作层之上用js另外模拟dom以达到减少dom操作的目的.我觉得很受启发,但细想一下,这一层如果是在浏览器中完成岂不是更快,为什么要在js库中实现呢?有什么具体原因么?求大神解答 --cut-- 题叶在1970-01-01 19:28:33回答到: 浏览器提供商想什么我不清楚,大致猜想大概会有这样一些考虑: 浏览器一般提供底层

  • Struts2与Spring3 MVC 性能对比(一)

    转载自 http://elf8848.iteye.com/blog/698217 你想建设一个能承受500万PV/每天的网站吗? 500万PV是什么概念?我的服务器每秒要处理多少个请求? PV是什么? PV是page view的简写.PV是指页面刷新的次数,每一次页面访问,就算做一次pv流量. 计算模型: 每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%))/服务器数量 其中关键的参数是80%.40%.表示一天中有80%的请求发生在40%的时间内.24小时

  • 移动WebApp开发 js框架

    1 目的 本次评比的目标是以移动Web App开发为基础的JS框架,会有意的排除部分不适用于移动Web App开发的JS框架,如 jQuery.ExtJS等.希望通过这次评比结果,能找到最合适你移动Web App应用开发的JS框架. 2 方法 由于JS框架在功能.特性和应用领域不同,所以,我将现在的主流JS框架分成四个大类: Mobilie Javascript Library.移动JS框架,在Desktop Javascript开发中具有代表性的JS框架有jQuery.ExtJS等,而在Mob

  • PayPal为什么从Java迁移到Node.js,性能提高一倍,文件代码减少44%

    大家都知道PayPal是另一家迁移到Node.js平台的大型公司,Jeff Harrell的这篇博文 Node.js at PayPal 解释了为什么从Java迁移出来的原因: 开发效率提高一倍(2个人用更少的时间干了5个人的活), 性能提高一倍, 代码量减少33%, 文件减少40%: (小编: 个人认为深层次原因是Java正在越来越走向封闭,而且变得越来越复杂而且oracle正在对Java收费,参见: Oracle计划发布收费版JVM , 这促使了越来越多的公司加入了去Java化的队伍) 外面

  • JQuery,Extjs,YUI,Prototype,Dojo 等JS框架的区别和应用场景简述(转)

    随着web2.0的彪悍发展,以及浏览器端所承载的工作越来越大(在不是很影响性能的情况下,开发者都习惯把能用浏览器做的事儿都让浏览器做,以减轻服务器的压力和带宽费用等). 所以Javascript已经成为了web开发最最基本的要求之一了. 而在现实的敏捷开发中,我们通常会选择一个JS框架来取代繁琐的Native Javascript的编写.你会发现这样会节省很多的时间,写的代码也很清晰便捷.(当然在学生时代的是有也质疑过,用框架会对原生态的 Javascript理解不深入,其实这是多虑了的.在对框

  • [转]JQuery,Extjs,YUI,Prototype,Dojo 等JS框架的区别和应用场景简述(一)

    随着web2.0的彪悍发展,以及浏览器端所承载的工作越来越大(在不是很影响性能的情况下,开发者都习惯把能用浏览器做的事儿都让浏览器做,以减轻服务器的压力和带宽费用等). 所以Javascript已经成为了web开发最最基本的要求之一了. 而在现实的敏捷开发中,我们通常会选择一个JS框架来取代繁琐的Native Javascript的编写.你会发现这样会节省很多的时间,写的代码也很清晰便捷.(当然在学生时代的是有也质疑过,用框架会对原生态的 Javascript理解不深入,其实这是多虑了的.在对框

  • 网易视频云技术分享:HBase BlockCache系列 - 性能对比测试报告

    网易视频云是网易公司旗下的视频云服务产品,以Paas服务模式,向开发者提供音视频编解码SDK和开放API,助力APP接入音视频功能. 现在,网易视频云的技术专家给大家分享一篇技术性文章:HBase BlockCache系列 - 性能对比测试报告. HBase BlockCache系列文章到了终结篇,几个主角的是是非非也该有个了断了,在SlabCache被早早地淘汰之后,站在华山之巅的也就仅剩LRU君(LRUBlockCache)和CBC君(CombinedBlockCache).谁赢谁输,我说了

  • PHP5.5四种序列化性能对比

    json_encode,serialize,igbinary,msgpack四种序列化方式,在之前已经有过相关的测试,PHP5.5这方面的测试暂时没有,这次测试基于PHP5.5,并且测试用例, http://blog.csdn.net/hguisu/article/details/7651730 的测试用例是一样的,只是从这个测试上家里igbinary serialize的测试,作为对比,可以参考 http://www.ooso.net/archives/538 运行环境 PHP5.5 内存 1

  • 图解JS框架教程

    以下介绍各种非jQuery的JS框架, jQuery另述.附上本人调试成功的截图和代码,和相关js文件. 一 backbone Backbone 为复杂Javascript应用程序提供模型(models).集合(collections).视图(views)的结构. backbone主要提供了3个东西:models(模型),collections(集合),views(视图).backbone.js文件压缩后只有5.3KB.这个JS还必须依赖于另一个JS文件:underscore.js(包含许多工具

Tags: