YUI 2.7.0 on TaskSpeed

April 13, 2009 at 2:21 pm by Luke Smith | In Development | 9 Comments

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

Chart of IE8 performance comparisons

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!

Share and extend: Bookmark with del.icio.us | digg it! | reddit!

9 Comments

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.

Comment by Eric Clemmons — April 13, 2009 #
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.

Comment by bruce — April 13, 2009 #
@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.

Comment by Eric Ferraiuolo — April 14, 2009 #
Is there a reason why Ext-JS core was left out of these tests?

Comment by Claude — April 15, 2009 #
@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!

Comment by bruce — April 15, 2009 #
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

Comment by Peter Higgins — April 20, 2009 #
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.

Comment by Eric Ferraiuolo — April 20, 2009 #
@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

Comment by Peter Higgins — April 20, 2009 #
To answer my own question… Tim Sporcic did include Ext-JS Core (beta) in a slickspeed test, take a look.

Comment by Claude — May 7, 2009 #

Sorry, the comment form is closed at this time.

Yahoo! User Interface Blog (YUIBlog)