测试场景：给 table 的 150 个 tr 添加style="color: #ccc", 重复 20 次。
测试页面：dom-manipulation.html

点击每个测试按钮前，都重新启动浏览器。手工记录 10 * 4 * 4 次无明显偏差的数据，取平均值，可得到以下统计结果：
dom manipulation spent time comparison chart

其它 DOM 操作结果类似。

结论：当页面较复杂，DOM 操作较多时，YUI3 会明显增加脚本执行时间，存在性能隐患。

原因分析

测试代码：

// jQuery 1.4
$("#test-table tr").css("color", "#ccc");

// YUI 3
Y.all("#test-table tr").setStyle("color", "#ccc");

用 Firebug 跟踪调用：
jQuery 基本调用链为：Sizzle – access(让 collection 有 css 方法) – css.
YUI 3 的调用链更复杂，甚至出现了 docHeight() 方法的调用。阅读源码可推测基本调用链为：Query – NodeList – Node – setStyle.

可以看出执行性能有三个方面：选择器性能、内部调用过程 和 setStyle 原子操作性能。

对于选择器来说，简单如#test-table tr, 经测试两者相差很小。
纯 setStyle 操作，两者也差不多。
可以判断：性能差异来自内部调用过程的设计。

思考

YUI3 的整体设计很漂亮，体现了 scalable（可大可小，能适用于小型站点也能搭建大型复杂应用） 的愿景。但这个 scalable 特性，目前看起来，仅体现在代码的模块组织以及灵活的组件加载和沙箱机制上。对于代码功能本身来说，YUI3 是个庞然大物。简单的功能，也需要历经设计优雅但执行漫长的内部调用过程。

感觉 YUI3 实际走向的是 ExtJS 路线。对于小型站点和快速应用来说，还是 jQuery 和 YUI2 好使。