YUI 2.7.0 on TaskSpeed
By Luke SmithApril 13th, 2009
A few months ago Peter Higgins, a contributor to the Dojo Toolkit, adapted the SlickSpeed test framework to do higher level comparisons of how various JavaScript libraries perform when doing some “common” DHTML tasks. The new test framework is called TaskSpeed. And thanks to the excellent work done by one of our favorite community members, Eric Ferraiuolo, YUI 2.7.0 now has representation in the matrix as well.
About TaskSpeed
Whereas SlickSpeed compares the performance of the respective JavaScript CSS selector engines in common libraries, TaskSpeed attempts to qualify a larger set of library functionality with less granularity. The goal seems to be to predict what a library consumer might expect for aggregate speeds when developing on top of library A vs. library B.
In addition to each of the participating libraries, a “PureDom” column represents the performance of the given task with plain old JavaScript and direct DOM interaction, serving as a healthy reminder that the benefits you get from using a JavaScript library don’t come for free. Unfortunately, “PureDom” might also be incorrectly construed as an argument in favor of not using a library at all, but that is a separate and lengthy discussion.
The results
Though YUI 2.7.0 was only added to the matrix on April 10th, the results submitted so far suggest that YUI performs the given tasks with comparable efficiency in the newer browsers, and better than most in Internet Explorer 6, 7, and 8.
IE 8 results from Apr 10 – Apr 13
Take-aways
Though YUI performs ably, it’s my opinion that the numbers seen in TaskSpeed should be taken with a hefty grain of salt. The tests are designed to exercise library abstraction logic against DOM-intensive operations. The issue here is twofold:
- Not all libraries (YUI included) have abstraction logic for all of the specific tasks, which breaks the apples-to-apples comparison.
- And in order to get meaningful numbers, the test operations are iterated up to 500 times or performed against excessive numbers of nodes. In real-world cases, these conditions are not the norm, meaning the differences are exaggerated, perhaps even grossly.
By and large, TaskSpeed may be more of a distraction than a source of information useful to the consumer. My greatest concern is that people will make a decision to choose one library over another based on which one can add a ridiculous number of event subscribers in 25 milliseconds vs. 30, ignoring more important issues like cross-browser stability, code maintainability, documentation quality, and community support.
This is not to say that TaskSpeed is without value. Here are the interesting take-aways I’ve found:
- Accounting for the lengthy iterations TaskSpeed needs to make the numbers substantial, all libraries perform common tasks pretty quickly.
- Libraries are getting faster, as seen by comparing version to version of the same library where available.
- There is a performance price to pay for the stability and consistency any library offers.
- For the library authors and contributors, an apples-to-apples comparison of task execution can highlight potential areas where we may each be able to evolve to use best-of-breed techniques for everyone’s benefit!
I’d like to personally extend a big “thank you” to Eric Ferraiuolo for having done the fantastic legwork on this. Another great example of the importance of community contributions to the YUI library!
April 13, 2009 at 2:29 pm
Any sort of benchmarking utility should be taken with a grain of salt, but they’re pretty important for certain tasks.
For example, suppose I generate custom charts and graphs for hundreds of terms on a page. If I’m making simple DOM adjustments (removing/adding elements & classes), then TaskSpeed will give some indication on what framework to use for that operation.
On the other hand, if I’m performing complex CSS Select queries on these hundreds of elements, then SlickSpeed will help determine the appropriate framework there.
April 13, 2009 at 3:12 pm
Interesting stuff, and well presented.
A minor quibble with the ‘finale’ test though; apparently the YUI way to clear the page is:
document.body.innerHTML = "";
… but PureDom has to do this:
while (body.firstChild)
body.removeChild(body.firstChild);
PureDom got a little shortchanged on that one! The PureDom developers should be on the street protesting with placards, I tell you.
April 14, 2009 at 10:13 am
@bruce When I was writing the finale test for YUI I looked inside Dojo’s empty method and they are setting the node’s innerHTML to “”. Since YUI doesn’t have an empty method, I did the same thing.
April 15, 2009 at 8:27 pm
Is there a reason why Ext-JS core was left out of these tests?
April 15, 2009 at 9:06 pm
@Eric – No complaints here, I only looked into it because I was curious how YUI got to be faster than pure DOM manipulation. I’d say you did the right thing, and it hardly matters anyway because all of Luke’s caveats about not taking these sorts of tests too literally are correct. Cheers!
April 20, 2009 at 6:08 am
Actually, the Dojo 1.2.3 tests are using _destroyElement in finaly. The YUI test should probably be adjusted to use the PureDom way, as innerHTML=”" won’t cleanup everything is should as the removeChild way (in IE, specifically). Dojo’s empty() uses innerHTML=”" on the fast path (where it knows it can) but uses removeChild where it must.
Regards,
Peter Higgins
Dojo Toolkit Project Lead
April 20, 2009 at 5:05 pm
I’ve updated the finale test for YUI 2.7.0 to match the strategy taken by PureDOM: looping over the body’s children and removing the Nodes one at a time. I’ve pushed the new code to my fork on GitHub.
April 20, 2009 at 7:37 pm
@Eric – Awesome, just got the update. Thanks for the quick turnaround. You guys have been such a joy to work with on this.
Regards,
Peter
May 7, 2009 at 3:33 pm
To answer my own question… Tim Sporcic did include Ext-JS Core (beta) in a slickspeed test, take a look.