It seems most of these tests are displaying results that are likely contrary to your objectives. Consider the following:
http://jsperf.com/concat-vs-array/4 According to jsperf building a string with 5000 concatenations compared to pushing into an array 5000 times and then using a single join method is about 16,000 times faster on Chrome and 22,000 times faster in Firefox. These are not real world results. The problem is not the test samples but what you are actually testing. You are not testing which test sample has the single fastest execution time, but rather how many times per second the execution can be processed. At first glance these would appear to be the same thing, because logically if one sample is faster to execute one time then it should run a higher number of continual times in a given period. Unfortunately, this is not a valid assumption provided the caching and compiling mechanisms that modern interpreters use. Modern interpreters use just in time (JIT) compilation, which is a scheme that interprets JavaScript like an old fashioned JavaScript interpreter, but then compiles that interpretation to byte code for faster execution the first time. JIT is not free, however. While it allows radically faster performance from the interpreting application it always works much harder at a lower level due to the compilation piece that did not use to exist in browser applications. Because this compilation does come with some costs it caches the compiled results in memory for reuse. This means there some difference in execution between the initial iteration and other iterations thereafter. This alone does not explain why jsperf tests are in error though. When the logic is compiled and stored it is already in memory awaiting some execution. If the input and the instructions are identical then it does not require further interpretation. Instead, all things on the JavaScript side being equal, the compiled instructions are fetched and executed again. This is problematic, because code in the real world does not work like this. In the real world input does change and so further interpretation is required. This means that in the real world single iteration execution time is valid and important. Specific to this code the factor that is disturbing the results is that a single join method is significantly slower than any single array push or string concatenation. Each cycle of the jsperf loop is stuck waiting on the join method. Here is the jsperf demonstration of those findings: http://jsperf.com/concat-vs-array/3 In the real world, however, you will typically find that pushing strings into an array an then using a single join method at the end will result in about 9.5 times execution speed compared to building output with string concatenation. The real world test becomes more valid and distinguishable as the number of loop iterations and string length increase. Thanks, Austin Cheney, CISSP -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Andrew Hedges Sent: Friday, October 14, 2011 6:01 PM To: [email protected] Subject: Re: [JSMentors] String Concatenation Performance This isn't a perfect test because it's using a loop rather than just using the + operator, but with 1000 strings, join is still only slightly faster. In other words (as per usual), do what is going to be most clear to the next developer unless you have good reason not to! http://jsperf.com/concat-versus-join ----- [email protected] / http://andrew.hedges.name/ On Sat, October 15, 2011 9:57 am, Brian Brennan wrote: >> >> using join on an array of strings, which, unsurprisingly is way slower in >> this case but can be faster when joining >> many strings > > > I do wonder: at what point does doing array join outperform concatenation? > Would it depend only on the number of items being concatenated or does > individual element length also matter? > > Brian > > > On Fri, Oct 14, 2011 at 4:47 PM, Andrew Hedges <[email protected]> wrote: > >> Hi Jess, >> >> I'm not sure what the purpose of the consumeURL function is if you just >> want to test the speed of >> assigning/concatenating strings. I made a modified test that strips out >> that part of things and adds another test case >> (using join on an array of strings, which, unsurprisingly is way slower in >> this case but can be faster when joining >> many strings). >> >> http://jsperf.com/string-concat-vs-long-lines/2 >> >> ----- >> [email protected] / http://andrew.hedges.name/ >> >> On Sat, October 15, 2011 9:25 am, Jess Jacobs wrote: >> > Hello everyone, >> > >> > I ran into an interesting issue while trying to prove that adding string >> > concats to a long running string simply to fit the "80 char/line" idea >> was >> > not a good thing. >> > >> > http://jsperf.com/string-concat-vs-long-lines >> > >> > I discovered, unless my tests have errors (please call 'em out if so!): >> > >> > 1. string declaration without concats is faster than concatenating two >> > strings (obviously) >> > 2. concatenating string + string is slower than concatenating var (with a >> > string value) + string (interesting) >> > 3. concatenating a var (string value) with a string is FASTER than >> declaring >> > a variable with only a string value (very interesting) >> > >> > The tests are vastly different for each browser, with Safari taking an >> > unbelievable lead in string processing over Chrome. Firefox came in dead >> > last of the three (I didn't test IE, but if someone wants to, I'm >> definitely >> > curious). Some test results differ even in which method is fastest in a >> > particular browser, but not typically by much. While the browser speed >> > differences were surprising to me, what's more surprising is item #3 >> above. >> > >> > Items 1 and 2 make a lot of sense to me; 1 being obvious, 2 I'm figuring >> > could be explained by primitive type conversion possibly not having to >> > happen due to one of the concat'd items already being a String object - >> but >> > now that I think about it, aren't they both primitive types since neither >> > were created as new String(), etc? 3, however, blows my mind. How on >> earth >> > is it faster to concat a var and a string and assign it to a var than it >> is >> > to simply assign a string value to a var? >> > >> > I'd really love to get way down to the nitty gritty on this, so anyone >> with >> > any insight, your replies are appreciated. Also would love to see any >> test >> > cases (more robust than mine) that could illustrate better what exactly >> is >> > going on here. >> > >> > Thanks, >> > Jess >> > >> > ======================== >> > Jess Jacobs >> > [email protected] >> > flavors.me/akisma - music, sound design, code. >> > >> > -- >> > To view archived discussions from the original JSMentors Mailman list: >> > http://www.mail-archive.com/[email protected]/ >> > >> > To search via a non-Google archive, visit here: >> http://www.mail-archive.com/[email protected]/ >> > >> > To unsubscribe from this group, send email to >> > [email protected] >> > >> >> -- >> To view archived discussions from the original JSMentors Mailman list: >> http://www.mail-archive.com/[email protected]/ >> >> To search via a non-Google archive, visit here: >> http://www.mail-archive.com/[email protected]/ >> >> To unsubscribe from this group, send email to >> [email protected] >> > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected] -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
