Especially if you are doing a lot of super-interactive user interface, you might also want to be sure that not only do you not blow away/recreate the event handlers (as you describe above), but that you use capture and bubble effectively. Hopefully you’re already doing that :)

One other idea: tuning your traversals is great, but don’t underestimate the extra performance suck that extra elements can cause. The more extraneous elements you can strip out, the faster everything will be. Including CSS selectors.

You might try also looking thru the other items on this JavaScript performance checklist I put out today: http://slowjavascript.com/

Nota bene: I am the co-author of JavaScript Performance Rocks! (http://jsrocks.com/), a book specifically about this very topic. It’s long and very thorough, you might find it helpful. :)

It’s funny: up until I read your article I’ve managed to completely neglect the fact that how the browsers handle CSS selectors may be completely different from how the popular JavaScript libraries handle them. This means that I need to start thinking more about having two different ways of optimizing CSS selectors: one for CSS statements (which are read right-to-left), and another strategy for optimizing the convenience selectors provided by jQuery, etc. Well.. guess it’s time to start digging around more in the jQuery code :)

“Buy $num hot dog” => “Buy 1 hot dog” / “Buy 25 hot dogs”

When integrated into Smarty or used to generate vars, can really clean up your code.

Post is here: http://thecodingway.com/blog/robs-tips-and-tricks/php-pluralizing-with-style/

The selectors module in mootools (and I imagine jquery) splits apart the selector into multiple parts and performs the fastest actions first.

If the selector contains an id, the element is recovered using the low level DOM method getElementById().

If the selector contains a tag, the list of candidate elements is computed using the low level DOM method getElementsByTagName().

If neither a tag nor an id are provided, the entire subtree must be searched.

For classes and pseudo elements, there is no low-level DOM call to find these, so each element must be checked one by one using JavaScript.

Adding the class to the selector thus helps speed things up by narrowing the list of tags to search through via a quick DOM call.

complex => complices

Should be complexes, imo. :)

The issue is that in many languages (such as C++ or Java), (j+15)/7 *is* an integer operation when j is an int. So for those of us who come from those languages (and who see the strong typing in AS3 as a move toward those languages), this is confusing.

Even if you argue that having this be a floating point operation is ‘better’ than having it be an integer operation, a modern compiler should be able to analyze the code to discover that the result of this operation is stored in an int and do an integer version of the division operation.

If I remember correctly, the player team investigated this approach, and found that it was difficult to get strictly correct behavior in edge cases (like dividing by NaN, etc). As a trade-off, they did an intrinsic conversion to Number in many cases that aren’t strictly necessary.

They may have improved this in more recent version of the VM. I haven’t worked at Adobe for 2 years, so I don’t really know what’s going on these days.

Your blanket statement that Number is better than int is not fair at all.

Your loop is doing an int() cast every single iteration. Of course this is going to be slow. Note the difference if you don’t divide by 7 and it doesn’t have to do a conversion.

var now:int = getTimer();
var j:int;
var i:int = 10000000;
while (i–)
{
j = (j + 15);
}
trace(getTimer() – now);

41ms

If you divide by 7

154ms

Obviously, doing floating point math using Number is faster than doing it with int. But doing integer math with int is MUCH faster than doing it with Number.

If you’re using floats, use Number. If you’re using integers, use int.