Using var l = imgs.length; while (l--) instead of a for-loop
No measurable effect on the speed of my loop, except that I had to reverse a sort order to account for the reverse traversal. And I don't like reversing sort orders, it's hard enough to keep these things straight when you're not counting backwards.
Not copying function args to local vars
I.e. instead of the redundant
var ctop = arg2, use arg2 directly. Made the code cleaner. Didn't have any measurable effect on runtime.Using object properties directly instead of copying them to local vars
I.e. instead of
var etop = e.cachedTop use e.cachedTop directly. Made the code cleaner, no effect on runtime.Using imgs[i] everywhere instead of var e = imgs[i]
That seems slower to me. And more typing. But, no measurable effect on runtime.
Using a > b ? a : b instead of Math.max(a,b), ditto for Math.min
This was one of my ideas. No measurable effect on runtime.
Inlining isVisible to the loop
Again, one of my ideas. Again, no measurable effect on runtime. Maybe a 5-10% improvement, but my measurement error is 10-20% :|
Moving setting e.trans outside the loop
Sounds like a good idea. Need to refactor my code to do that.
Conclusions
Most of the things people tell you will improve JavaScript performance actually don't. Measure.
Also, I need a better way to measure runtimes. What I have now is a keydown handler that runs the loop a hundred times and prints the elapsed time to Firebug console. The amusing thing is that the exact same code can give 100-run runtimes ranging from 550 ms to 720 ms. And my system load is zero.
I suppose the problem is that this benchmark is run as part of my existing application. So, if any enterprising soul wants to have a go, make the bit you benchmark a separate page.
