一次失败的jQuery优化尝试小结

(这并不意味着jQuery的性能是优秀的, 反之只能说它是一个相对封闭的库,无法从外部介入进行优化)。这篇文章就记录一次失败的优化经历。
优化思想
这一次优化的思想来自于数据库。在数据库优化的时候,我们常会说“将大量的操作放在一个事务中一起提交,能有效提高效率”。虽然对数据库不了解的我并不知道其原因,但是“事务”的思想却为我指明了方向(虽然是错的……)。
因此我尝试将“事务”这一概念引入到jQuery中,通过“打开”和“提交”事务,从外部对jQuery进行一些优化,其最重要的在于减少each函数的循环次数。
众所周知,jQuery的DOM操作,以get all, set first为标准,其中用于设置DOM属性/样式的操作,几乎都是对选择出来的元素的一次遍历,jQuery.access函数就是其中最核心的部分,其中用于循环的代码如下:


代码如下:

// Setting one attribute
if ( value !== undefined ) {
// Optionally, function values get executed if exec is true
exec = !pass && exec && jQuery.isFunction(value);
for ( var i = 0; i < length; i++ ) {
fn(
elems[i],
key,
exec ? value.call(elems[i], i, fn(elems[i], key)) : value,
pass
);
}
return elems;
}

比如jQuery.fn.css函数就是这样的:


代码如下:

jQuery.fn.css = function( name, value ) {
// Setting 'undefined' is a no-op
if ( arguments.length === 2 && value === undefined ) {
return this;
}
return jQuery.access( this, name, value, true, function( elem, name, value ) {
return value !== undefined ?
jQuery.style( elem, name, value ) :
jQuery.css( elem, name );
});
};

因此,下面这样的代码,假设被选择的div元素有5000个,则要循环访问10000个节点:
jQuery('div').css('height', 300).css('width', 200);
而在我的想法中,在一个“事务”中,可以如数据库的操作一般,通过保存所有的操作,在“提交事务”的时候统一进行,将10000次节点访问,减少至5000次,相当于提升了“1倍”的性能。
简单实现
“事务”式的jQuery操作中,提供2个函数:
begin:打开一个“事务”,返回一个事务的对象。该对象拥有jQuery的所有函数,但是调用函数并不会立刻生效,只有在“提交事务”后才会生效。
commit:提交一个“事务”,保证所有事先调用过的函数都生效,交返回原本的jQuery对象。
实现起来也很方便:
创建一个“事务对象”,复制jQuery.fn上所有函数到该对象中。
当调用某个函数时,在预先准备好的“队列”中添加调用的函数名和相关参数。
当提交事务时,对被选择的元素进行一次遍历,对遍历中的每个节点应用“队列”中的所有函数。
简单地代码如下:


代码如下:

var slice = Array.prototype.slice;
jQuery.fn.begin = function() {
var proxy = {
_core: c,
_queue: []
},
key,
func;
//复制jQuery.fn上的函数
for (key in jQuery.fn) {
func = jQuery.fn[key];
if (typeof func == 'function') {
//这里会因为for循环产生key始终是最后一个循环值的问题
//因此必须使用一个闭包保证key的有效性(LIFT效应)
(function(key) {
proxy[key] = function() {
//将函数调用放到队列中
this._queue.push([key, slice.call(arguments, 0)]);
return this;
};
})(key);
}
}
//避免commit函数也被拦截
proxy.commit = jQuery.fn.commit;
return proxy;
};
jQuery.fn.commit = function() {
var core = this._core,
queue = this._queue;
//仅一个each循环
core.each(function() {
var i = 0,
item,
jq = jQuery(this);
//调用所有函数
for (; item = queue[i]; i++) {
jq[item[0]].apply(jq, item[1]);
}
});
return this.c;
};

测试环境
测试使用以下条件:
5000个div放在一个容器(<div id="container"></div>)中。
使用$('#container>div')选择这5000个div。
每个div要求设置一个随机背景色(randomColor函数),和800px以下的随机宽度(randomWidth函数)。
参加测试的调用方法有3个:
正常使用法:


代码如下:

$('#container>div')
.css('background-color', randomColor)
.css('width', randomWidth);

单次循环法:


代码如下:

$('#container>div').each(function() {
$(this).css('background-color', randomColor).css('width', randomWidth);
});

事务法:


代码如下:

$('#container>div')
.begin()
.css('background-color', randomColor)
.css('width', randomWidth)
.commit();

对象赋值法:


代码如下:

$('#container>div').css({
'background-color': randomColor,
'width': randomWidth
});

测试浏览器选择Chrome 8系列(用IE测就直接挂了)。
悲伤的结果
原本的预测结果是,单次循环法的效率远高于正常使用法,同时事务法虽然比单次循环法慢一些,但应该比正常使用法更快,而对象赋值法其实是jQuery内部支持的单次循环法,效率应该是最高的。
然而遗憾的是,结果如下:
正常使用法 单次循环法 事务法 对象赋值法
18435ms 18233ms 18918ms 17748ms
从结果上看,事务法成了最慢的一种方法。同时单次循环与正常使用并没有明显的优势,甚至依赖jQuery内部实现的对象赋值法也没有拉开很大的差距。
由于5000个元素的操作已经是非常庞大的循环,如此庞大的循环也没能拉开性能的差距,平时最常用的10个左右的元素操作更不可能有明显的优势,甚至还可能将劣势扩大化。
究其原因,由于本身单次循环法就没有明显的性能提升,因此依赖于单次循环,并是在单次循环之上进行外部构建的事务法,自然是在单次循环的基础上还需要额外增加创建事务对象、保存函数队列、遍历函数队列等开销,结果败给正常使用法也在情理之中。
至此,也算是可以宣布模仿“事务”的优化之道的失败。但是对这个结果却还能进一步地分析。
性能在哪里
首先,从代码的使用上来分析,将正常使用法和测试中最快的对象赋值法进行比较,可以说两者的差距仅在于循环的元素个数的不同(这里抛开了jQuery的内部问题,事实上jQuery.access的糟糕实现也确实有拖对象赋值法后腿之嫌,好在并不严重),正常使用法是10000个元素,对象赋值法是5000个元素。因此可以简单地认为,18435 - 17748 = 687ms是循环5000个元素的耗时,这占到整个执行过程的3.5%左右,并不是整个执行过程的主干,其实真的没有优化的必要。

那么另外96.5%的开销去了哪里呢?谨记Doglas的一句话,“事实上Javascript并不慢,慢的是DOM的操作”。其实剩下96.5%的开销中,除去函数调用等基本的消耗,至少有95%的时间是用在了DOM元素的样式被改变后的重新渲染之上。

发现了这个事实之后,其实也就有了更正确的优化方向,也是前端性能中的基本原则之一:在修改大量子元素时,先将根父DOM节点移出DOM树。因此如果使用以下的代码再进行测试:


代码如下:

//没有重用$('#container')已经很糟糕了
$('#container').detach().find('div')
.css('background-color', randomColor)
.css('width', randomWidth);
$('#container').appendTo(document.body);

测试结果始终停留在900ms左右,与前面的数据完全不在一个数量级之上,真正的优化成功。

教训和总结
千万要找到正确的性能瓶颈再进行优化,盲目的猜测只会导致走上错误而偏激的道路。
数据说话,数据面前谁也别说话!
不认为“事务”这个方向是错误的,如果jQuery原生就能支持“事务”这样的概念,会不会有其他的点可以优化?比如一个事务自动会将父元素脱离出DOM树之类的……

(0)

相关推荐

  • 一次失败的jQuery优化尝试小结

    (这并不意味着jQuery的性能是优秀的, 反之只能说它是一个相对封闭的库,无法从外部介入进行优化).这篇文章就记录一次失败的优化经历. 优化思想 这一次优化的思想来自于数据库.在数据库优化的时候,我们常会说"将大量的操作放在一个事务中一起提交,能有效提高效率".虽然对数据库不了解的我并不知道其原因,但是"事务"的思想却为我指明了方向(虽然是错的--). 因此我尝试将"事务"这一概念引入到jQuery中,通过"打开"和&quo

  • 基于Redis实现延时队列的优化方案小结

    目录 一.延时队列的应用 二.延时队列的实现 三.总结 一.延时队列的应用 近期在开发部门的新项目,其中有个关键功能就是智能推送,即根据用户行为在特定的时间点向用户推送相应的提醒消息,比如以下业务场景: 在用户点击充值项后,半小时内未充值,向用户推送充值未完成提醒. 在用户最近一次阅读行为2小时后,向用户推送继续阅读提醒. 在用户新注册或退出应用N分钟后,向用户推送合适的推荐消息. … 上述场景的共同特征就是在某事件触发后延迟一定时间后再执行特定任务,若事件触发时间点可知,则上述逻辑也可等价于在

  • Vue 打包体积优化方案小结

    Vue-cli3 打包体积优化方案 前言: 公司项目完成后 ,打包完成后有1.18MB,其实感觉还行了,但是还可以有优化的地方,对于咱们有精益求精(有没有还是有点*数的)的精神下再去优化,可以先在项目中安装webpack-bundle-analyzer可以看到各个文件的大小 npm install webpack-bundle-analyzer -save-dev 在vue.config.js中进行配置 module.exports = { chainWebpack: config => { c

  • 浅谈webpack 构建性能优化策略小结

    背景 如今前端工程化的概念早已经深入人心,选择一款合适的编译和资源管理工具已经成为了所有前端工程中的标配,而在诸多的构建工具中,webpack以其丰富的功能和灵活的配置而深受业内吹捧,逐步取代了grunt和gulp成为大多数前端工程实践中的首选,React,Vue,Angular等诸多知名项目也都相继选用其作为官方构建工具,极受业内追捧.但是,随者工程开发的复杂程度和代码规模不断地增加,webpack暴露出来的各种性能问题也愈发明显,极大的影响着开发过程中的体验. 问题归纳 历经了多个web项目

  • Jquery优化效率 提升性能解决方案

    例如有一段HTML代码: 1.总是从ID选择器开始继承 以下是引用片段:<div id="content">  <form method="post" action="#">  <h2>交通信号灯</h2>  <ul id="traffic_light">  <li><input type="radio" class="

  • MYSQL表优化方法小结 讲的挺全面

    同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法,因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能. 安装好mysql后,配制文件应该在/usr/local/mysql/share/mysql目录中,配制文件有几个,有my- huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环

  • webpack常用构建优化策略小结

    简介 读了<深入浅出webpack>总结一下常用的webpack的构建优化策略,可通过以下手段来提升项目构建时的速度 更精准的loader规则 将loader规则写清楚 仅让需要处理的文件,进入loader处理环节,如下 rules: [{ // 正则尽量准确 test: /\.js$/, // 使用缓存,缓存后在文件未改变时编译会更快(缓存查找原理见补充1) use: ['babel-loader?cacheDirectory'], // 指定需要处理的目录 include: path.re

  • mysql -参数thread_cache_size优化方法 小结

    说明: 根据调查发现以上服务器线程缓存thread_cache_size没有进行设置,或者设置过小,这个值表示可以重新利用保存在缓存中线程的数量,当断开连接时如果缓存中还有空间,那么客户端的线程将被放到缓存中,如果线程重新被请求,那么请求将从缓存中读取,如果缓存中是空的或者是新的请求,那么这个线程将被重新创建,如果有很多新的线程,增加这个值可以改善系统性能.通过比较 Connections 和 Threads_created 状态的变量,可以看到这个变量的作用.(-->表示要调整的值) 根据物理

  • jQuery Selector选择器小结

    //jQuery 选择器 $ //$(expression,[context]) return jQuery //Unit One //expression 之 CSS 定义符 就是以CSS语法表示所要选择的元素 // $("*"); // 表示页面所有元素标签 // $("th, td") // 表示所有<th><td>元素标签 // $("a") // 表示所有<a>元素标签 // $("div#

  • JQuery基础语法小结

    1.$(document)将document对象转换为jquery 复制代码 代码如下: $(document).ready(function(){     alert("hello world"); }); 2.获取所有的超链接对象,并且增加onclick事件:其实在底层jquery对象获得的每个标签的数组,因此我们不需要进行循环了 复制代码 代码如下: $(document).ready(function(){     $("a").click(function

随机推荐