Performance issues with "String Concatenation" in JScript.

Techy News Blog » Performance issues with “String Concatenation” in JScript.

Techy News Blog » Performance issues with “String Concatenation” in JScript. — Wed, 17 Oct 2007 15:54:24 GMT

PingBack from http://www.artofbam.com/wordpress/?p=9573

re: Performance issues with "String Concatenation" in JScript.

Lionel — Wed, 17 Oct 2007 17:41:57 GMT

> Numbers speak for themselves.

Very nice! :-)

> You will have to wait till next release of Internet Explorer.

Waiting is hard... :-(

re: Performance issues with "String Concatenation" in JScript.

Matt Ellis — Wed, 17 Oct 2007 19:00:17 GMT

Nice one JP! But after reading Eric's post that you linked to, I'm really interested to know what algorithm you've used to fix it. Any chance of a behind-the-scenes look?

Cheers

Matt

re: Performance issues with "String Concatenation" in JScript.

SharpGIS — Wed, 17 Oct 2007 19:45:39 GMT

Seems like a vaste of time for me. Even in JScript there are a much better way to concatenate strings than this by using a string builder approach. And we can use that with todays browsers (and of course we all do right?) This is no different from what we should be doing in all the other programming languages we use, because they all have this problem with string copying.

Having that said, The JScript performance is one of IE's biggest achilles heals these days, and it's good news that you are optimizing it. VML rendering and mousemove needs some clean up too.

re: Performance issues with "String Concatenation" in JScript.

shabunc — Thu, 18 Oct 2007 01:57:26 GMT

Oh, just great.

Listen me. guys, we have an almighty algorithm, but we can not describe it.

re: Performance issues with "String Concatenation" in JScript.

Martijn Coppoolse — Thu, 18 Oct 2007 11:19:46 GMT

That's why I've been using arrays to concatenate strings for, oh, about ten years now.

To quote JPJ's examples:

var x = [];

for (var i = 0; i < count; i++) {

x.push(s);

}

x = x.join('');

Output:

Time taken to += 'jscript' 20000 times : 875 ms

Time taken to push 'jscript' 20000 times : 78 ms

And the other one is simply rewritten:

resultStr = ['Jscript', 'String', 'Append'].join('');

re: Performance issues with "String Concatenation" in JScript.

Shabunc — Thu, 18 Oct 2007 14:17:16 GMT

Martijn Coppoolse, yor approach is excellent for IE, but if you want to have a cross-broser decision, you should mention that Array.join approach is the worst in Firefox and not the best in Opera.

re: Performance issues with "String Concatenation" in JScript.

shivaram.p — Tue, 23 Oct 2007 18:47:18 GMT

Thanks for the feedback guys. The algorithm we have used is somewhat similar to what Eric mentioned in his blog. As I said it is still under testing and may need some changes.

As Martin and SharpGIS mentioned, folks have been using Array.push() and Array.join() approach to concatenate strings in IE, but still not everyone knows about it. New developers still fall back to using direct string concatenation approach, which hurts perf and causes lot of extra work. So why not have all of them performant and let developers concentrate on 'task in hand' rather than 'best practices' :).

- JP

re: Performance issues with "String Concatenation" in JScript.

anphanax — Thu, 25 Oct 2007 04:37:15 GMT

I do not know where the VBScript people are (or if they even have a blog), or if you're all part of the same team. I am very curious as to whether or not VBScript will be getting this sort of enhancement too, given how much classic ASP in VBScript is still out there and the large amount of other scripts written in it.

It kind of sucks going through a script written that does a TON of string concatenation (which cannot be avoided with how it is written) and converting the code to use Join(Array(...), "").

[Suresh] We own VBScript too. VBScript is under sustaining engineering mode for quite some time and we are not planning any new DCR. However we are there to address any blocking issues for the customers. We shall treat this as a bug and plan for a fix.

re: Performance issues with "String Concatenation" in JScript.

Tino Zijdel — Fri, 26 Oct 2007 01:20:24 GMT

I wrote an article about this last year: http://therealcrisp.xs4all.nl/blog/2006/12/09/string-performance-in-internet-explorer/

bottom line is that a stringbuilder approach isn't optimal either because of IE's poor performance in all the other areas and you would either have to fork your code for IE or experience degraded performance in other browsers who do have decent string-handling performance.

It's good that MS is finally doing something about this long-standing issue, I do have however one question: will JScript in future also support accessing strings as a character-array like all other ECMA-compliant implementations?

For example: alert('foo'[2]) should give me 'o'

re: Performance issues with "String Concatenation" in JScript.

Rasmus — Mon, 29 Oct 2007 16:15:21 GMT

Should be possible to get a nice speedup by avoiding some of the long string copies. Something like:

var blocksize = 10;

for (var i = 0; i < count / blocksize; i++) {

var tmp = "";

for (var j = 0; j < blocksize; j++) {

tmp += s;

}

x += tmp;

}

This way the number of string copies are the same, but a lot of them are copying short strings instead of long strings.

re: Performance issues with "String Concatenation" in JScript.

Jaiprakash — Mon, 29 Oct 2007 16:26:14 GMT

Absolutely right. The current implmentation gets slower ans slower as string size increases. It's nice work around to append small strings, and then generate a big string out of them.

-JP

re: Performance issues with "String Concatenation" in JScript.

Jorrit Schippers — Thu, 01 Nov 2007 01:07:20 GMT

What is holding you from putting this fix in a next update of current versions? It's not a crime to release performance updates after a products release.

re: Performance issues with "String Concatenation" in JScript.

rektide — Tue, 06 Nov 2007 08:12:11 GMT

i suggest mentioning array.join in the article, such that less new programmers have to be lightly bruised with sticks for their crimes. regardless of ie's performance, the problem is not string concatenation, its the people who use it.

re: Performance issues with "String Concatenation" in JScript.

UUDIBUUDI — Fri, 21 Dec 2007 01:43:29 GMT

I use this all the time in HTA's, simple, easy to read and pretty efficient (i lookup the length of the array so I can add stuff to the output without having to increase a counter). No extra functions / classes needed! :)

var output = new Array();

for (var i = 0; i < 1000; i++) {

output[output.length] = i;

}

alert(output.join(''));

re: Performance issues with "String Concatenation" in JScript.

Photowiz — Fri, 21 Dec 2007 01:55:41 GMT

This is not a waste of time, SharpGIS. Whether you can improve string performance is not relevant to the thousands of web pages already existing that use string builders.

re: Performance issues with "String Concatenation" in JScript.

Keith — Fri, 21 Dec 2007 03:48:15 GMT

This article would have been more accurately titled: "Performance issues with "Extremely Long String Concatenation" in JScript."

Because, unfortunately I think it's a flawed test that will mislead lots of readers of that thread can have them use a less attractive coding pattern that can be up to 3x *slower*, to do a simple thing like concatenate two strings. I will post my tests to the thread.

I think that "fixing" our code according to that article would actually reduce our performance.

The problem with the example given is that it creates a very specific, non-realistic test that tickles a particular known code path. Specifically, it repeatedly adds a small string to an extremely long one. That is *not* a real world use case, and if it is, then yes, people should use one of the supplied alternative patterns (and, of course, MS should fix their implementation in any case).

That IE's JS performs particularly poorly in this regard is evidenced by the non-linear performance times (and perhaps that's why JP didn't show us, e.g. 1k iterations, or 1 or 20 iterations, which are quite good). This is also mentioned by a follow-up poster.

Normally one loops a performance test many times and then divides by the number of iterations to see what the single-iteration cost is, but that is not accurate in JP's test. Essentially, JP's test tells us nothing about how long it takes to do a single string concatenation or even 1000, it only tells us how long it takes to create a very long string via 20k iterations.

What, then, if we did a more realistic test, which actually tested what real code is doing? I did that and you'll see that the results are far better *and* far more linear.

I've included two such tests here, as well as my timings for JP's tests, Martin's tests, and my tests. You'll see that in the normal case, IE has stellar performance. I also included a "1000" iteration number so you can see the linearity of the various tests.

JP’s code: 20k iterations (1000 iterations):

IE: 34000ms (300ms) (yes, you read that right)

FF: 83ms (4ms)

Martijn Coppoolse ArrayTest (super long strings): 20k iterations (1000 iterations):

IE: 63ms (2ms)

FF:120ms (5ms)

Keith ArrayTest: 20k iterations (1000 iterations)

IE: 164ms (6ms)

FF: 312ms (15ms)

Keith ConcatTest1 (+): 20k iterations (1000 iterations)

IE: 43ms (1ms)

FF: 76ms (1ms)

Keith ConcatTest2 (+=): 20k iterations (1000 iterations)

IE: 51ms (1ms)

FF: 109ms (6ms)

**** THE CODE ****

ARRAYTEST

var before = new Date().getTime();

var s1 = "11111";

var s2 = "22222";

count = 20000;

for (var i = 0; i < count; i++) {

x = [s1, s2];

x.join('');

}

var after = new Date().getTime();

var time = after - before;

alert("ARRAY TEST(.join): Time taken to append '"+s1+"'+'"+s2+"'(="+x+") " + count + " times : " + time + " ms");

CONCAT TEST1 (+)

var before = new Date().getTime();

var s1 = "11111";

var s2 = "22222";

count = 20000;

for (var i = 0; i < count; i++) {

x = s1+s2;

}

var after = new Date().getTime();

var time = after - before;

alert("CONCAT1 TEST(+): Time taken to append '"+s1+"'+'"+s2+"'(="+x+") " + count + " times : " + time + " ms");

CONCAT TEST2 (+=)

var before = new Date().getTime();

var s1 = "11111";

var s2 = "22222";

count = 20000;

for (var i = 0; i < count; i++) {

x = "AAAAA";

x += s2;

}

var after = new Date().getTime();

var time = after - before;

alert("CONCAT2 TEST(+=): Time taken to append '"+s1+"'+'"+s2+"'(="+x+") " + count + " times : " + time + " ms");

re: Performance issues with "String Concatenation" in JScript.

Jaiprakash — Thu, 27 Dec 2007 16:34:28 GMT

Thanks Keith for such detailed example and numbers. I really appreciate it. I agree that I should have stated that problem lies in creating big strings through multiple string concatenation, not small strings. However I feel that contents in the blog convey this. Pls. check out the section "How it affects Real world Scenarios" and the paragraph just above it where I have explained the reason behind IE's slowness.

One more thing I would like to mention is that most of the Jscript benchmarks floating around do such concatenations to test the string concatenation performance.

- JP

re: Performance issues with "String Concatenation" in JScript.

Josh Stodola — Tue, 01 Jan 2008 02:30:07 GMT

While it was overall great to read this, it is horrible, pathetic, and gut-wrenching to hear is that we must wait for the next release of Internet Explorer before we can BEGIN to utilize the fix!

I don't understand why you can't patch IE7...? Go ahead and take a look and see the stats on how many people currently use IE6.

http://www.w3schools.com/browsers/browsers_stats.asp

Now consider how long it will be before the majority of IE users will be running the next release (scheduled for 2009?).

RIDICULOUS.

re: Performance issues with "String Concatenation" in JScript.

Ricky — Tue, 08 Jan 2008 09:02:23 GMT

Is this algorithm available in IE7 patch?

Ricky.

re: Performance issues with "String Concatenation" in JScript.

Jaiprakash — Tue, 08 Jan 2008 13:23:54 GMT

I believe you mean script 5.7. Sorry, it is not there.

-JP

re: Performance issues with "String Concatenation" in JScript.

Webdesign — Sat, 19 Jan 2008 16:11:54 GMT

re: Performance issues with "String Concatenation" in JScript.

Tweak Vista — Sat, 19 Jan 2008 16:12:16 GMT

re: Performance issues with "String Concatenation" in JScript.

Meubelstoffering — Sat, 19 Jan 2008 16:19:23 GMT

Nice one JP! But after reading Eric's post that you linked to, I'm really interested to know what algorithm you've used to fix it. Any chance of a behind-the-scenes look?

re: Performance issues with "String Concatenation" in JScript.

LFERC — Sat, 19 Jan 2008 16:19:54 GMT

> Numbers speak for themselves.

Very nice! :-)

> You will have to wait till next release of Internet Explorer.

Waiting is hard... :-(

StringBuilder en JavaScript : concatenation de String

Atteint de JavaScriptite Aiguë [Cyril Durand] — Sun, 17 Feb 2008 05:19:40 GMT

En JavaScript, comme en .net ou ava, les strings sont immutables cela veut dire que l'objet ne peut pas

re: Performance issues with "String Concatenation" in JScript.

timeless — Thu, 28 Feb 2008 13:14:51 GMT

please note that "abc"[1] is not required by ECMA. JScript is not doing anything wrong. It's technically an extension.

JScript in Internet Explorer 8 Beta 1 for Developers

JScript Blog — Wed, 05 Mar 2008 23:53:51 GMT

Making developers more productive through the design, development, and debug phases of web application

IE8 Beta1 is available

Visual Studio to Internet Explore... — Fri, 07 Mar 2008 10:45:21 GMT

IE8 Beta1 is now available here . It has remarkable script improvements in JScript performance. It also

Insight into String Concatenation in JScript

JScript Blog — Wed, 19 Mar 2008 13:54:42 GMT

Hello Friends, Have you read my post on the String Concatenation issue? If yes, then I can sense your

re: Performance issues with "String Concatenation" in JScript.

RobG — Tue, 05 Aug 2008 15:48:58 GMT

Good to see you are working on this, but IE is still way slower than other browsers.

possibly related - Performance issues with "String Concatenation" in JScript.

Mr. Raymond Kenneth Petry — Wed, 14 Jan 2009 01:10:27 GMT

Dear JP☺,

My application is a screenplayformatter, so I get lots of performance issues (my screenplays are particularly big: 2hr-4hr, 9hr the latest) and I've been improving it 2-years since my first attempt pre contenteditable (I use some neat 'tricks' eg. to get all indentations of a type to adjust at-once, disabled=true,false)!

Here's a current issue: I'd like to generalize my script-source to include doc/rtf/txt/html... anything that 'looks' like a script ...

But,--

Copy-Paste takes an inordinate amount of time ('ordinateur', is French for computer)-- when the source is rtf: MSIE-itself converts quickly to html, but paste-html into contenteditable-- takes yah-yah-yah... Okay... So,-- I'd like to catch the html from the clipBoard and condense the long P-SPAN-O:P-...(on every line) leaving just the indentation for my pre-parser ... BUT clipBoard html isn't available... just-- text.

I'd like the html or indentationed-html source from the clipBoard.... Please, and, Thank you.

Cordially, sincerely,

Ray.

P.S. You know why I paste into contenteditable: WRAP, takes inordinate time; So, I wrapper the DIV in CITE to get the fastest onPaste=getData ca 3 sec./MB,- and okay for a 6hr script. Ray.