jQuery运行程序性能目的和调优

jQuery无疑是一个杰出的JavaScript库,但它的性能如何?在其易用性和优秀Web页面性能之间启动折衷能否值得?它的性能是不是真的很优秀?本文将回答关于jQuery性能的疑问,并提供一些可以改良运行程序性能的技巧。

介绍专题:

度量JavaScript性能要思考的最关键疑问是执行JavaScript的环境。由于代码是运转在客户端上的,所以它的执行依赖于客户端计算机,这使得客户端机器成为影响性能的最关键要素。很清楚,运转4核CPU的新主机执行代码的速度必要求比MHz老式处置器快。这是毫无不懂的。不过,由于您不能控制Web运行程序用户用于访问您的站点的机器,所以在度量性能时要思考关于配件的许多要素。

JavaScript性能的另一个关键方面是用于运转JavaScript的阅读器,JavaScript新手或许不容易觉察这个影响要素。每个阅读器外部都蕴含一个JavaScript引擎,即用于解析和执行JavaScript代码并处置Web运行程序页面的本机代码。因此,JavaScript的性能严重依赖于客户端经常使用的阅读器,并且在某些状况下,您可以控制用户经常使用的阅读器。本文提供一些关于JavaScript性能的指点准则,并解释不同阅读器对性能的影响。

创立性能测试

关于性能测试的***步是创立一个适宜的性能测试。jQuery以及其余JavaScript库在代码中表演的最关键角色就是经常使用选用查找特定页面元素。我在最后的性能测试中就以这方面为重点。一个良好的性能测试应该真正地施展JavaScript库的所有力气,用蕴含数千个页面元素的页面测试它。应该运转一切选用方法,让我看到哪个选用方法最快,哪个最慢。测试应该事前知道正确的答案,从而确定JavaScript库能否正确地执行选用方法。***,应该显示一切结果,并附带所用的运转期间,让我能够在一切库之间启动比拟。

我差点疏忽了性能测试的最关键方面:它应该是收费的。毕竟这个系列文章的不成文规定就是相互应用彼此的成绩,因此我继续发扬这种精气,在此经常使用一个现成的JavaScript库性能测试。这个测试称为SlickSpeedSelectorsTest,它十分适宜我的需求。它将jQuery1.2.6(撰写本文时的***版本)与其余4个盛行的JavaScript库(MooTools、Prototype、YUI和Dojo)启动比拟。而后,它经常使用带有数千个页面元素的页面运转40个选用测试。换句话说,这是我所宿愿的***性能测试。我将在***共性能测试剖析中经常使用该测试。

对比JavaScript库的性能

关于***共性能测试,我经常使用的运转环境是2.2GHz处置器、2GBRAM和Firefox3.0.3(十分关键)。我在该性能下运转5次测试,图1显示了5次运转的平均结果。

图 1.性能测试1的结果

从***次测试能够得出什么论断?如今咱们仅关注总体结果,而不是每次测试。在取得一些总体论断之后,我将稍后在本文中关注每个测试。

论断1:YUI慢到了极点

对,与其余库相比,YUI真的很慢。细心检查每个测试,找出为什么这个库在选用元素组(例如“p,a”)时十分慢。关于要求具备很好性能的页面而言,这个库是最差的选用。

论断2:Mootools、jQuery和Dojo的运转期间简直一样

与其余两个库相比,这3个库是十分快的,并且Dojo是它们当中最快的,而jQuery是最慢的。但是从全局思考,它们之间的速度是很凑近的。

论断3:这些库之间的相对差异还是比拟清楚的

度量最快期间/最慢期间以确定速度的相对差异,您可以看到相对差异为332%。这个差异是比拟大的,这标明经常使用Firefox时选用不同的JavaScript库会对性能有影响。但是要记住,这些论断仅基于一个阅读器的结果。这是基于Firefox3.0.3得出的论断。如今咱们进入下一小节,我将在不同的阅读器上运转该测试。

在不同阅读器上的JavaScript性能

面对不同阅读器运转JavaScript会得出的不同结果(性能和期间都不同),许多初级Web程序员感觉无法思议。虽然这对初级Web程序员而言是个曲折(他们担忧要编写额外的代码来处置不同的阅读器),但是有阅历的Web程序员在Netscape和InternetExplorer的早期就知道如何处置该疑问。这也是经常使用JavaScript库的一个亮点,由于它们都审慎处置许多或大局部阅读器差异。

JavaScript速度差异的关键要素是每个阅读器都经常使用自己的JavaScript引擎。JavaScript引擎是用于解析JavaScript并依据Web运行程序执行它的本机代码。因此,JavaScript的执行速度与底层引擎间接关系。在最近几个月,许多阅读器公司越来越关注他们的阅读器的性能,这是有要素的。随着某些页面的JavaScript变得日益复杂,JavaScript引擎的快慢能够影响Web运行程序的照应速度。因此,当Google和Firefox等公司议论它们的JavaScript引擎时,它们就谈判及下一代引擎的速度要快10倍。这对Web运行程序而言是很关键的,由于底层JavaScript引擎的速度间接造成更复杂的Web运行程序的发生。

如今,您知道JavaScript引擎是JavaScript执行速度的一个要素,那么让咱们在不同的阅读器上运转刚才在Firefox上运转的测试,并尝试找出不同的引擎对JavaScript性能的影响。记住,这个测试与我前面在Firefox上运转的测试是一样的,因此除了JavaScript引擎以外,其余一切物品都是相反的。图2显示了测试结果。

图2. 性能测试2的结果

看完这些测试结果之后,您首先留意到的是在这些阅读器中运转获取的期间差很大。在Chrome1.0上运转jQuery要求168毫秒,而在IE6上运转要求1728秒。这是难以置信的期间差!jQuery选用方法在IE6上运转比在Chrome上运转慢10倍!如今,您知道为什么Google青睐炫耀它的JavaScript引擎,以及为什么某些阅读器很少引见自己的JavaScript引擎。这些差异还是比拟大的。

您应该留意到,jQuery在Firefox或一些其余阅读器上运转时速度排在第3位,而在另一些阅读器上排在第1位。理想上,这些结果标明,依据性能启动分类的话,这些库可以分为两组,而不论经常使用什么阅读器。Mootools、Dojo和jQuery通常属于一个组别,而Prototype和YUI属于另一个组别,前一组要比后一组快得多。

性能测试论断

我感觉一切这些论断都要求专门花一个小节启动论述,由于它们对JavaScript开发人员十分关键。我依然尝试总结上方的性能结果,并且没有遗记本文是以jQuery为主题的。

论断1:Mootools、jQuery和Dojo在性能方面不分高低

图3. 测试结果的平均值(Mootools、jQuery 和 Dojo)

检查它们在一切5个阅读器上启动的测试,在求取平均值之后,您可以看到这3个库的性能简直是一样的。(理想状况下,咱们应该考查每个阅读器的市场份额。但是调整这些数字很难,由于经常使用JavaScript库的站点不必定由“平均用户”访问)。

论断2:Prototype和YUI的性能很慢

看看这两个库在5个阅读器中的测试结果与jQuery的对比。在求取它们的平均值之后,您可以发现这两个库的性能差异有多大。它们在恣意阅读器中平均比jQuery慢300%。

图4. 测试结果的平均值(jQuery、Prototype 和 YUI)

论断3:假设对性能要求比拟高时,选用Mootools、jQuery和Dojo之一取得的性能简直一样

依据以上的平均值,选用这3个库之一比选用另外两个库之一能够取得更多的性能长处。从在一切阅读器上运转得出的平均值看,它们的性能是相当的。因此,当您选用JavaScript库时,选用这3个库之一是不会错的。

论断4:假设对性能要求比拟高时,不要选用Prototype或YUI

假设要求JavaScript库具备较高的性能,或许计划创立一个大型的JavaScript名目,那么就不应该选用这两个库之一。这两个库的性能要比其余库逊色得多。

论断5:阅读器对性能的影响是JavaScript库的9倍

我以为这是本文一切论断中最关键的论断。您可以在特定状况下讨论哪个JavaScript库最快,但它最终的影响却是很小的!关于性能而言,阅读器的影响比库自身要大得多。回忆一下图3和图4的平均值,您可以看到3个最快的库中,最慢那个(Dojo)仅比最快那个(jQuery)慢15%。只要15%!

但是,您看看jQuery在最快的阅读器(Chrome1.0)和最慢的阅读器(IE6)上运转的速度差异,这个差异居然到达1000%!从这两个数字看,15%对1000%而言是微无余道的。至此,关于3个较快的库中哪个是最快的争执可以中止了,由于它们对最终结果的影响是微乎其微的。

论断6:假设JavaScript性能对Web运行程序很关键,并且您可以控制选用什么阅读器,那么就选用最快的阅读器

在某些状况下,您可以控制经常使用什么阅读器访问站点。假设能够控制经常使用什么阅读器,那么您就是很幸运的。我就碰到这样幸运的名目。在这种状况下,假设您领有一个复杂的JavaScript运行程序,或许您以为性能很关键,那么您就应该控制用户用于访问Web运行程序的阅读器。这些测试曾经清楚地显示了阅读器的影响。假设您的JavaScript运行程序的访问量很大,那么您可以通知用户,他们必需经常使用Chrome。

论断7:假设您不能控制用户经常使用的阅读器,那么要首先思考在IE6上的性能

但是,在大局部状况下,咱们都无法控制用户经常使用什么阅读器访问咱们的站点。不过,很大一局部用户都经常使用IE6阅读网页。到目前为止的测试中,这个阅读器的JavaScript引擎是最慢的。但是由于依然有少量用户经常使用它,并且良好的Web设计要求“顺应最蹩脚的状况”,这象征着您可以思考依据IE6设计您的JavaScript运行程序。

jQuery性能调优

本文的第二局部将讨论如何改良jQuery代码的性能。前一局部标明选用jQuery作为JavaScript库指向了正确的性能方向。假设您正在阅读本文,您或许曾经经常使用了jQuery。但是底层库速度快并不象征着您编写的一切代码都是高品质的。假设您没有回过头来想想应该怎样做,经常使用jQuery依然会编写出十分慢的代码。

这个局部引见一些性能调优常识,以及改良jQuery代码速度的***通常技巧。

技巧#1-尽或许多地经过ID启动搜查,而不是CLASS

图5. ID搜查和CLASS搜查对比

在jQuery代码中两种经常出现的搜查技术是经过元素的ID启动搜查和经过元素的CLASS启动搜查。在经常使用惯例JavaScript的JavaScript库之前,经过ID查找页面元素还是相当便捷的。可以经常使用getElementById()方法极速找到元素。但是假设没有JavaScript库,要查找CLASS会愈加艰巨,在必要状况下,咱们还经过在其ID中启动编码协助查找。

经常使用jQuery时,搜查CLASS就像搜查页面上的ID一样便捷,因此这两个搜查仿佛是可调换的。但是实践状况并非如此。经过ID搜查比经过CLASS搜查要快得多。当经过ID启动搜查时,jQuery实践上仅经常使用内置的getElementById()方法,但经过CLASS启动搜查时必需遍历页面上的一切元素,以查找婚配项。很清楚,当页面越大并且越复杂时,经过CLASS启动搜查会造成照应十分慢,而经过ID启动搜查不会随着页面变大而变慢。

前面运转的jQuery性能测试结果支持这一数据。让咱们检查每个测试,看看要求留意jQuery代码的什么中央。在这个例子中,区分看看经过ID和CLASS启动搜查时的测试结果。

这些测试是不同的,但它们得出的数据标明经过ID启动搜查比经过CLASS启动搜查快得多。这如何影响到jQuery代码?在编写搜查时,您要记住这些技巧:假设既可选用CLASS又可选用ID,那么通常要选用ID。假设要求在您的代码中搜查某些元素,必定要给它们调配ID。清单1显示了一个实践的jQuery测试,您可以在您的机器上运转它对此启动验证:

ID测试耗时218毫秒,而CLASS测试耗时19.9秒!甚至在专门为该测试构建的便捷页面上,ID搜查也要比CLASS搜查快100倍!

技巧#2-提供尽或许多的搜查信息

图6. 尽或许多地提供信息

jQuery提供如此多的页面元素搜查方法,有时您难以指出哪种方法是***的。有一条阅历是不会错的,即为搜查参数提供尽或许多的信息。因此,假设您正在搜查带有“clickable”CLASS的一切页面元素,假设您提早知道仅有DIV附带有CLASS,那么就能提高搜查性能。所以,搜查“div.clickable”会愈放慢。图6显示了支持该技巧的结果。

思考究竟层JavaScript代码之后,这就无余为奇了。经过提供元素标志,与CLASS参数婚配的搜查元素数量将大大缩小,从而将搜查性能优化至与本例中的ID搜查相当。开发人员在编写jQuery选用方法时不能偷懒,虽然jQuery的便捷让人发生偷懒的愿望。便捷让您安适了警觉。搜查机制变得如此便捷,让咱们偏差于仅输入一条信息。但是,您应该总是尽或许多地输入信息,尤其是已知信息。清单2显示了一个很好的例子。

技巧#3-缓存选用器

***一共性能技巧应用了简直一切jQuery选用器都前往jQuery对象这个特性。这象征着无理想的状况下,您仅要求运转选用器一次性,并且能够轻松地将一切函数衔接在一同,或缓存结果供经常使用。您也不要担忧缓存,由于与总体可用内存相比,前往的对象是很小的。清单3给出了一些关于如何应用缓存的例子。

在我的***一个关于性能的示例代码中,将检查我在本系列的***篇文章中提到的小部件(见参考资料)。这个小部件是在表的左上角上的复选框,它准许您选用或敞开选用该列上的一切复选框。这个小部件在电子邮件运行程序中十分经常出现,用于选用或敞开选用一切信息。

关于性能的要点

经常使用JavaScript时,速度和性能相对不是小疑问。无理想中,创立jQuery的开发人员和处置阅读器内置JavaScript引擎的开发人员都十分关注性能疑问。理想上,在最近6个月以来,阅读器开发的最关键疑问就是JavaScript引擎的速度。阅读器开发者都努力于在下一年迅速优化JavaScript的执行性能,从而大大提高jQuery代码和JavaScript引擎的速度。来自这些“速度之战”的信息标明,优化JavaScript性能是大势所趋。

指导jQuery名目的JohnResig不时都在议论他的***“Sizzle”选用引擎。他从头编写了一个选用引擎,并宣称初步结果标明它比Firefox要快4倍。这是渺小的速度优化!在我撰写本文的***局部时,jQuery1.3曾经颁布,并且蕴含了Sizzle选用引擎。jQuery宣称,在一切阅读器上运转的总体结果标明选用引擎的1.3版本比1.2.6版本的快49%。此外,1.3颁布版在HTML注入(向DOM增加新的元素)上改良了6倍,在函数定位上改良了3倍。在我成功本文时,很多人都更新到了***的jQuery颁布版,这是十分令人激动的!

影响JavaScript性能的另一个要素是阅读器,如前所述,它的影响是所选的库的9倍。Firefox和Chrome在“最快JavaScript引擎”之战中各有输赢,而Safari的介入让竞争愈加强烈。从咱们上方的测试中,可以看到Chrome在JavaScript引擎性能方面远远超越Firefox,但是Firefox3.1将蕴含新的TracemonkeyJavaScript引擎,届时其速度将比的JavaScript引擎3.0快20至40倍(这是他们宣称的,不是我的观念),真无法思议!在未来一两年内,您将看究竟层JavaScript引擎和JavaScript库的速度获取渺小改良,从而导以至用JavaScript的Web运行程序将变得愈加复杂。

假设您正在选择是经常使用JavaScript库还是自己编写JavaScript,那么要求思考的另一件事件是处置和调试JavaScript库所需的所有上班。最近几年以来,有数百位用户不时在保养库中的每一个函数。您或许要忙到深夜,甚至精疲力竭地编写自己的函数。

您更置信谁呢?另外,即使您能编写出比jQuery库更快的代码,您能否想过经常使用jQuery库能够取得更多的长处?您能否为了辛劳地编写自己的代码而丢弃经常使用十分便利的jQuery及其函数库?自己编写代码不只要求少量期间,并且还会发生更多bug,因此我还是倡导经常使用现成的jQuery库。

我***讨论的要点或许会让一些人丧气,但是咱们必需思考编写这些jQuery库的程序员。他们当中的一些是最棒的,并且他们编写的超级优秀的代码(普通人不能编写这样杰出的代码)都支出到这些库中。我抵赖自己远远不如编写jQuery库的程序员。因此,为何不应用他们的智慧?

完结语

本文从总体上讨论了jQuery和JavaScript库的性能。经过对选用方法启动少量的测试,您看到这些库之间的速度存在渺小的差距,并且jQuery是最快的库之一。不过,即使您选用了最快的JavaScript库,还是不能处置Web运行程序的性能疑问,由于阅读器对性能的影响比库强9倍。假设您能够控制用户经常使用特定的Web阅读器,那么就让他们经常使用最快的阅读器。找到能够最快地运转您的Web运行程序的阅读器,并让用户经过经常使用它从中受益。理想状况下,让最慢的JavaScript阅读器隐没象征着发生更快的Web运行程序。

***,咱们极速检查了jQuery和阅读器的JavaScript引擎行将推出的改良。在我撰写本文的开头局部时,jQuery1.3曾经颁布了,它承诺在选用和代码的其余方面成功腾跃式性能改良。此外,Firefox还承诺它的下一代JavaScript引擎会快20至40倍!这些迹象标明,在未来的一两年内,JavaScript环境会在性能上取得严重打破。在不久的未来,复杂的Web运行程序会日益盛行,由于极速运转这些程序的条件曾经成熟。

【编辑介绍】

您可能还会对下面的文章感兴趣: