@all - thanks for all the comments. Love the heated discussion. @RobG - can you code up some example code as to how you would solve the same problem I presented code for?
And while it is off topic...can you provide the code you used to run the benchmarking? I'm not challenging your results, just want to see and fiddle with them. For example, instead of just adding 10k span nodes, make it 400 table rows with 5 tds and 5 links. Have the table rows and tds all have a class, the links a class and an href and text and compare that against a string with the same. I bet the creation, attribute setting, and insertion will take a lot longer. As for adding 10,000 elements to a page... I am adding up to 500 rows to a table with 6 tds in each row and a link in 5 of those tds and text in the other... so that is 500 * 6 * 6, or up to 18,000 nodes. @Kean - Yes, join is faster... usually. If speed is of the utmost importance, then I test using it because I have had it end up being slower. Otherwise, I use += because it's more legible. Even with the 18,000 node case I mentioned above, += finishes up in 486ms in FF 3.0.8 which more then meets our requirements. I haven't even benchmarked it with Chrome, but I would guess significantly less. There are a lot of other things that can be done to speed up insertion first that make a much larger impact. See my aforementioned article, it's a great discussion, I've just been involved in it several times :). Thanks all, Josh On Apr 16, 12:06 pm, Kean <shenan...@gmail.com> wrote: > @Josh Powell > - string concatenation is plenty fast 99% of the time and a lot more > readable. > Yes string concatenation is more readable and 99% faster for normal > usage. But looping and concatenate a huge chunk in this particular > case is slower. Reason: every + between 2 strings returns a new string > before concatenating with other strings. Array.prototype.join does not > have that problem. You just need more than 6 string concatenation > (subject to string length and debate) and it will be a good choice for > Array.prototype.join to take over. > > - W3C DOM Node creation is much slower then inserting via innerHTML, > especially as you add more nodes. It doesn't matter how fast the > nodes are created, it will always be slower to create, adjust, and > insert 10,000 nodes then one string. > That's old school thinking. Please refer to my original post, I am > talking about Chrome's v8 engine and browser detection. You will be > pleasantly surprised. See RobG's comment too. > > @RobG > Thanks for benchmarking.
