selector性能

先说selector效率优化策略三条:
1. 最右边的自选器精准化，以减少海选数。
 “.aaa”优化成“input.aaa”-----海选*.aaa变成了海选input.aaa
 “.ctn .aaa”优化成“.ctn input.aaa”-----海选*.aaa变成了海选input.aaa
2. 带上容器id，以减少海选数。
 “div.aaa”优化成“#container div.aaa”-----海选div.aaa变成了海选#container input.aaa
3. 除带id祖先或带id旁系亲属外，关系尽量简单，以减少血缘鉴定难度。
 “body input.aaa”优化成“input.aaa”-----减少了一层没必要的关系。

写页面的同学在很多情况下可以忽略性能（选择器已经做了很多优化），
但是一些基本的优化策略，还是应该放在心里的。

那我们再来看下selector性能比赛吧。
以司徒同学的新锐选择器作的速度的比赛试例为例(http://www.cnblogs.com/rubylouvre/archive/2010/01/27/1657684.html)，来看下这个比赛到底有少可以再考虑的地方。

selector	简评
body :empty	多一层无效血缘鉴定。----也有部分选择器对body作了特别优化，会把它唯一性祖先看。 自选器没带tagName，考虑能否精准化
div:not(.example)	:not使用情况较少，速度比赛没有对使用概率进行加权，John Resig曾经写过一篇文章，统计过常用selector的使用概率的问题。
p:contains(selectors)	:contains使用情况较少
div p a	三层血缘鉴定，血缘鉴定成本有点过高。参见“优化策略3”
div, p, a	有“,”关系符，sizzle默认进行排序与除重。所以很慢。----默认排序有利有弊，很多selector放弃了这一策略。
div p	血缘鉴定耗时
body div	多一层无效血缘鉴定。----也有部分选择器对body作了特别优化，会把它唯一性祖先看。
.note	自选器没带tagName，考虑能否精准化
ul.toc li.tocline2
ul.toc > li.tocline2
tr .pattern	自选器没带tagName，考虑能否精准化
p
div
div ~ p	使用概率低
div > div	使用概率底
div ~ div	使用概率低
div > p	使用概率低
body	部分选择器对body有优化
div + p	使用概率低
div[class^=exa][class$=mple]
div.example	使用概率高。并且是推荐用法。可以考虑加权因素
ul .tocline2	自选器没带tagName，考虑能否精准化
div.example, div.note	有“,”关系符，sizzle默认进行排序与除重。所以很慢。----默认排序有利有弊，很多selector放弃了这一策略。
#title	使用概率高。并且是推荐用法。可以考虑加权因素
h1#title
div #title
h1#title + div > p	后半段使用概率低
a[href][lang][class]
div[class]
div[class=example]
div[class^=exa]
div[class$=mple]
div[class*=e]
div[class|=dialog]
div[class!=made_up]
div[class~=example]
p:nth-child(even)
p:nth-child(2n)
p:nth-child(odd)
p:nth-child(2n+1)
p:nth-child(n)
p:only-child
p:last-child
p:first-child
div :only-child	使用概率低。 多一层血缘鉴定。 自选器没带tagName，考虑能否精准化
div :only-of-type	使用概率低。 多一层血缘鉴定。 自选器没带tagName，考虑能否精准化
th:first-of-type	使用概率低。
th:last-of-type	使用概率低。
td:nth-of-type(even)	使用概率低。
td:nth-last-of-type(odd)	使用概率低。
td:odd
p:even

综上，分析一下主要的几个问题：
速度比赛里，大部分的时间，都花在使用概率低、或是可以考虑改进的selector写法上。
所以，比赛的总分，参考意义不是很大。细看每项，可能收获更多。

唯一特别的“,”关系符。sizzle好像没有认真面对这个问题----也许的确现实中没多少人这么用。
目测：在有“,”选择符时，sizzle没有优化ie下的排序，不然，600多个元素，要花200ms，有点夸张。
在IE下，用以下这种方法sortBy(resultArr,function(el){return el.sourceIndex+100000000;})，耗时应该会减小到20ms以内吧----想当然的认为，没测过。
https://github.com/wedteam/qwrap/blob/master/resource/js/core/dev/array.h.js

 

 

作者: JKisJK 发表于 2011-01-28 06:08 原文链接