John.

In regards to cloneNode, I used to think the same thing…then I tested it. cloneNode on a cache object inside a function is slower than createElement due to the overhead of the function call & the object hash lookup. Prototype -may- be getting a bit of a speed bump by using coneNode in new Element() since the function call has already been done, but that speed gain is -very- small and is greatly trumped by the overhead of the rest of the function. In general what I’ve realized is that cloneNode on a SINGLE node is almost never worth it (as of IE7, Safari3, FF2)

http://www.rockstarapps.com/samples/performance/

2) On the speed of for…in iteration for arrays, don’t use for…in for array iteration. It’s EEEEEEEEVILLLLL! Running a counter with an iterator variable is vastly more efficient. There are times when it’s worth reducing code size by a few characters, and there are times when it’s not. (see http://www.uize.com/tests/performance/array-iteration-styles.html)

3) For additional performance with the counter approach to array iteration, storing the value of the .length property in a local variable also helps (as long as the array will not be modified in length during the operation). Repeated dereferencing of the length property of the array object costs a bit.

Array.join is a lot faster on IE6 that is why it is used. But as as IE6 share decreases, javascript developers should take note and update their code accordingly. Otherwise people will continue to do it for no reason. It’s kind of like how a lot of javascript developers still put a html comment inside of there script tags still. There is no reason to do it anymore.

http://www.sitepen.com/blog/wp-content/uploads/2008/05/stringfor.png

Specifically at the core advice “Use Array.join instead of += on a string” was directly contradicted by the data I collected during the string performance analysis I wrote about; the link above shows clearly that += beats out both using Array.join and String.prototype.concat on all major browsers.

- JDD