Comments on: String Performance in IE: Array.join vs += continued http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued Cleaning up the web with Ajax Thu, 09 Feb 2012 06:55:33 +0000 hourly 1 http://wordpress.org/?v=3.2 By: andyli http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued/comment-page-1#comment-275894 andyli Sat, 10 Oct 2009 11:59:12 +0000 http://ajaxian.com/?p=3731#comment-275894 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/ 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/

]]> By: Aphrodisiac http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued/comment-page-1#comment-266709 Aphrodisiac Fri, 15 Aug 2008 13:18:11 +0000 http://ajaxian.com/?p=3731#comment-266709 very intresting thanks very intresting
thanks

]]> By: ttrenka http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued/comment-page-1#comment-264970 ttrenka Tue, 10 Jun 2008 19:33:45 +0000 http://ajaxian.com/?p=3731#comment-264970 <blockquote>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.</blockquote> ...preaching to the choir. There's many different solutions that serve better purposes for different people; that's the beauty of the Open Web. <blockquote>Why? It seems downright anti-user to me.</blockquote> 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. <blockquote>“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.</blockquote> 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).

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).

]]> By: eyelidlessness http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued/comment-page-1#comment-264967 eyelidlessness Tue, 10 Jun 2008 18:43:06 +0000 http://ajaxian.com/?p=3731#comment-264967 "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). “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).

]]> By: ttrenka http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued/comment-page-1#comment-264966 ttrenka Tue, 10 Jun 2008 18:27:29 +0000 http://ajaxian.com/?p=3731#comment-264966 <blockquote cite="eyelidlessness">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.</blockquote> 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. . <blockquote cite="eyelidlessness">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.</blockquote> 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 (tm). . PS: I like your solution for separating paragraphs on the comments here, think I'm gonna lift it from now on :)

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 :)

]]> By: eyelidlessness http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued/comment-page-1#comment-264965 eyelidlessness Tue, 10 Jun 2008 18:17:23 +0000 http://ajaxian.com/?p=3731#comment-264965 @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. @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.

]]> By: ttrenka http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued/comment-page-1#comment-264963 ttrenka Tue, 10 Jun 2008 17:26:50 +0000 http://ajaxian.com/?p=3731#comment-264963 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. 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.

]]> By: timsamshuijzen http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued/comment-page-1#comment-264950 timsamshuijzen Tue, 10 Jun 2008 13:51:47 +0000 http://ajaxian.com/?p=3731#comment-264950 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). 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).

]]> By: eyelidlessness http://ajaxian.com/archives/string-performance-in-ie-arrayjoin-vs-continued/comment-page-1#comment-264932 eyelidlessness Tue, 10 Jun 2008 05:26:15 +0000 http://ajaxian.com/?p=3731#comment-264932 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. 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.

]]>