Monday, June 9th, 2008

String Performance in IE: Array.join vs += continued

Category: IE, JavaScript, Performance

<p>

Tom Trenka has followed up his last post on String performance with a deep dive on IE that dispells the myth of Array.join.

Tom goes through tons of tests across versions of IE and using varying sizes of data.

In Conclusion

First things first—with the performance improvements with IE7, we no longer need to consider using an alternate path when doing large scale string operations; using Array.join in an iterative situation gives you no major advantages than using += in the same situation. In addition, the differences with IE6 were slight enough to allow you to not bother forking for that specific version.

The only time considering using an array as opposed to a string for these kind of operations is when you are aware that the fragments you are appending are very large (on the order of > 65536 bytes); doing this will cause the GC issues Dan Pupius talks about in his analysis of object allocation and the JScript garbage collector.

From there, we can progress to programming techniques—with Internet Explorer, it is much better to call Builder.append with as many arguments as possible than to simply iterate and push things in one at a time.

It is also better to start small; try to structure your string operations so that very large string operations are minimized. In this case, using a temporary buffer to assemble a set of strings together and then adding them to a much larger string is better than constantly adding small fragments to a larger string.

And as always, minimizing the size of an iteration will help get extra performance out of JScript.

The raw numbers have been made available to scour over.

Related Content:

9 Comments »

Comments feed TrackBack URI

What the hell are people doing with strings that requires so much energy spent on this? I’ve never done a string concat operation that took enough time to notice in any browser.

Given how much attention to the issue has waned, I don’t think I’m alone.

Comment by eyelidlessness — June 10, 2008

As an example of large string concatenations, look at this website:

http://www.megabooksearch.com/

Example: search for Author “kerouac”. Once the search results are presented on the List page, you can sort the (large) table by clicking any of the column headers (client side sorting). The entire table is rebuilt using string concatenations. I then use innerHTML to re-display the table (I know, innerHTML is bad bad bad, it just seemed to be the fastest method).

Comment by timsamshuijzen — June 10, 2008

That is one use for it (and was the original method I’d used back for the Dojo 0.3 SortableTable). Another use is serializing the contents of a document–say you have an Editor of some sort (like FCKEditor or the Dijit Editor), and you want to post the contents of that editor as pure XHTML…you would walk the DOM of the contents of the editor and create a string out of it using string concatenation. There are many uses for large string operations in JavaScript; it may not be of interest to anyone doing simple things on a site but it should be of interest to anyone doing a bit more than that.

Comment by ttrenka — June 10, 2008

@timsamshuijzen:
“sort the (large) table by clicking any of the column headers (client side sorting)”
.
Well that’s all fine and good, but it’s probably better both for usability and for performance to paginate the results, at which point the performance difference would be pretty minimal. Another benefit is that, given that an Ajax response would likely be faster for sorting across pages than client-side sorting of non-paginated data, you can essentially just build the table itself server-side and drop it in in innerHTML.
.
“I then use innerHTML to re-display the table (I know, innerHTML is bad bad bad, it just seemed to be the fastest method).”
.
Of course it’s the best method for table operations, especially given IE’s idiocy in handling DOM operations on tables.
.
@ttrenka:
“Another use is serializing the contents of a document–say you have an Editor of some sort (like FCKEditor or the Dijit Editor), and you want to post the contents of that editor as pure XHTML…you would walk the DOM of the contents of the editor and create a string out of it using string concatenation.”
.
Really? That seems like it could be better accomplished server-side, especially by not treating the data as text-only but using a solid DOM library of some sort.
.
“There are many uses for large string operations in JavaScript; it may not be of interest to anyone doing simple things on a site but it should be of interest to anyone doing a bit more than that.”
.
Hey, I’m doing plenty of things at least that complex (including building implementations of both of these examples!), but when I start seeing operations like that where something like string performance becomes an obvious problem, I start to rethink the process and find ways to offload or avoid the expensive operations.
.
I really think that if this is such a pressing issue you might want to rethink either the process or the UI or both.

Comment by eyelidlessness — June 10, 2008

Really? That seems like it could be better accomplished server-side, especially by not treating the data as text-only but using a solid DOM library of some sort.

If you’re doing editor work (you implied that below this quote) then you’ll know that what comes out of the editors in each browser is very different. You could most certainly process that server-side (and some do) but I personally know a number of others that would prefer to offload that onto the client.
.

Hey, I’m doing plenty of things at least that complex (including building implementations of both of these examples!), but when I start seeing operations like that where something like string performance becomes an obvious problem, I start to rethink the process and find ways to offload or avoid the expensive operations.
.
I really think that if this is such a pressing issue you might want to rethink either the process or the UI or both.

Sometimes you don’t have that option, but I agree–when string performance is killing your app, you definitely have a problem.
.
But the goal here was to try to determine the best techniques possible based on the way the various browsers handle strings, in a way that is accurate and informative. I happen to know quite a few advanced developers who not only find this interesting but will also find ways to apply it to their own code–which is A Good Thing ™.
.
PS: I like your solution for separating paragraphs on the comments here, think I’m gonna lift it from now on :)

Comment by ttrenka — June 10, 2008

“If you’re doing editor work (you implied that below this quote) then you’ll know that what comes out of the editors in each browser is very different.”
.
Yep. But that’s actually a great argument in favor of processing server-side: using a common DOM library for cleaning up all output means the output is consistent before you save it.
.
“I personally know a number of others that would prefer to offload that onto the client.”
.
Why? It seems downright anti-user to me.
.
“Sometimes you don’t have that option”
.
That’s fair, I guess I probably do take for granted the flexibility I’m allowed in developing when compared to a lot of folks working for larger companies.
.
“PS: I like your solution for separating paragraphs on the comments here, think I’m gonna lift it from now on :)”
.
Someone who posts on here uses the paragraph symbol, which I like more, but I can never remember the keyboard shortcut for it! Too bad it’s impossible to get the Ajaxian folks to fix really glaring but simple-to-fix design problems with the site (the other being videos/images often being too wide for the content area).

Comment by eyelidlessness — June 10, 2008

Yep. But that’s actually a great argument in favor of processing server-side: using a common DOM library for cleaning up all output means the output is consistent before you save it.

…preaching to the choir. There’s many different solutions that serve better purposes for different people; that’s the beauty of the Open Web.

Why? It seems downright anti-user to me.

I think that can really depend on the size of the documents being edited and what kind of performance hit you might take walking a tree. Most of the time (in my experience) the documents are small enough to not let that process get in the way of the user experience but every situation is different.
.
The main thing is that as a dev, you have all options open, I think.

“Sometimes you don’t have that option”
.
That’s fair, I guess I probably do take for granted the flexibility I’m allowed in developing when compared to a lot of folks working for larger companies.

Yes…when I get to work on smaller projects I get used to the flexibility as well. But when you start working on enterprise-level ones you might be surprised at the kinds of constraints you end up having to work around (again, I can tell you that one from a lot of experience).

Comment by ttrenka — June 10, 2008

very intresting
thanks

Comment by Aphrodisiac — August 15, 2008

I’ve just found out that in Chrome 3, using the concat method of String is x7000 SLOWER than the other two (+= and Array join)!!

Try my test here:
http://blog.onthewings.net/2009/10/09/as3-js-string-concatenation-methods-performace-test/

Comment by andyli — October 10, 2009

Leave a comment

You must be logged in to post a comment.