Posts Tagged ‘dom’

Using Sizzle with Prototype

March 24th, 2009

Recently, John Resig of jQuery fame released the selector engine used in the new version of jQuery called Sizzle.  Sizzle is a new take on using CSS selectors within Javascript and aims to be far more efficient than the methods commonly used by most current Javascript libraries.

Currently, I'm working on a large project that is nearly ready to deploy.  Most of the Javascript for this project has been written using the Prototype framework; however, we wanted to leverage the speed of the new Sizzle selectors engine in our project.  Given that we are deep in the QA process of the project, large code changes are discouraged to ensure code stability.  What we needed was a quick way to integrate Sizzle with Prototype.

The following code can be added to your Prototype 1.6.x file and will ensure that prototype's main element collection methods (Element#select and $$) both use Sizzle.  I've written before on how slow $$ can be, so these are two quick wins for Prototype performance.

//Overwrite findChildElements to use Sizzle http://sizzlejs.com
Selector.findChildElements = function(element, expression){
    expression = expression.join(", ");
    var results = Sizzle(expression, element);
    if(results.length > 0){
        for(var i=0; i < results.length; i++){
            results[i] = Element.extend(results[i]);
        }
    }
    return results;
};

Comments »

Posted in briancrescimanno.com

Tags:

Performance is in the Details

May 29th, 2008

This past week, some colleagues and I sat around a brainstorming table trying to isolate what was causing a particular page to load incredibly slowly in Internet Explorer 6. Drawing on our combined years of experience, and our mutual disdain for IE6, we came up with what we believed to be a solid list of potential bottlenecks that included (among other things):

  1. DOM Parsing (the DOM is very large for this particular page)
  2. Slow / Inefficient Ajax requests
  3. Parsing large JSON strings returned by Ajax request
  4. Too many event handler assignments

We tested each of these theories among the 5-6 others that we had collected and could not find any particular area that was acting particularly slow. Unfortunately, the lack of any serious profiling tools for IE made the task of doing real benchmarks almost impossible. We scratched our heads and adjourned for our 3-day weekend.

In the process of fixing random software defects, one of our other lead engineers stumbled across this line of code that one of our more junior engineers had checked in:

for(var i=0; i < $$('div.contents').length; i++)

My head was spinning just looking at that one statement. For those unfamiliar with Prototype, the $$ method is a sometimes useful, but horribly inefficient means of searching the DOM. In plain English, this method will walk the entire DOM of your document, and check if it matches the CSS selector contained within, and add a reference to that element to an array if it does. When the traversal is complete, the array is returned. Do you see the problem now? Each time the loop ran (conceivably 50+ times in this case, however many elements matched div.contents) it would have to do an entire DOM traversal. Additionally, it would have to calculate the length of the returned array each time!

For reference, as a service to all of the other engineers-those who don't yet know as well as those who have had to clean up after someone who didn't know, better practice would be:

var contents = $$('div.contents');
var length = contents.length;
for(var i=0; i < length; i++)

However, it would be far more advisable to restrict your search of the DOM using prototype's Element.select method to only check the portions of the DOM.

The important take-away here is that you need to exercise extreme caution when using any method that traverses the DOM; especially as long as IE6 is a large player in the browser market as its DOM traversal is notoriously slow. Prototype's $$ is an especially dangerous method (even when used properly) and should only be employed in cases when it truly makes sense—that is, when you need to check the entirety of the document. Far more often, you will know a containing element from which to base your search:

var oddRows = $("container").select("li.odd");

Finally, always remember to calculate all of your parameters outside of a for statement (as in example 2 above). Doing so as part of the statement frankly reeks of the kind of amateur development practice one might get from reading a collection of some of the worst technical books on the market as for some reason they all seem to advocate this kind of thing.

DOM Traversal is expensive. Know what you're looking for and determine the best way to find it; not the easiest.

Comments »

Posted in Development

Tags: