>>the question still remains, though: why does test case 1 ("var and string
concat") outperform test case 3 ("no concat")?First of all it does by very little. The reason is the way most JS compilers handle string manipulation. When you assign a string to a variable in JS most compilers will process the string, which takes some time (the longer the string is, the longer the time), to check for escaped characters, etc, assign it to a temporary memory store, see where the string is being assigned to and assign it to that variable. With concatenation you are processing less instantiated string, your just grabbing stuff from memory, already processed, and processing quite a bit less. String concatenation isn't actually that expensive in most modern browsers, see the test case that I added. It can be expensive in IE7, but that's because IE7 is really stupid about strings. BTW, there is no reason to console.log the results in jsPerf, they make sure to cancel out any browser cheating that would occur, and a log wouldn't fool Chrome anyway. On Fri, Oct 14, 2011 at 3:37 PM, Jess Jacobs <[email protected]>wrote: > the question still remains, though: why does test case 1 ("var and string > concat") outperform test case 3 ("no concat")? in other words, why does it > cost more to assign a string literal to a variable than it does to concat a > string literal with a variable (containing a string literal) and assign that > to a variable? > > ======================== > Jess Jacobs > [email protected] > flavors.me/akisma - music, sound design, code. > > > > On Fri, Oct 14, 2011 at 11:54 AM, Jess Jacobs > <[email protected]>wrote: > >> Word - that's probably the only perf book I haven't gotten yet, and now is >> the time! Thanks for pointing it out. >> >> ======================== >> Jess Jacobs >> [email protected] >> flavors.me/akisma - music, sound design, code. >> >> >> >> On Fri, Oct 14, 2011 at 11:52 AM, Nick Morgan <[email protected]>wrote: >> >>> Hey Jess >>> >>> If you're interested in these kinds of micro-optimisations, I'd >>> recommend the book High Performance JavaScript by Nicholas Zakas (one >>> of the mentors). There's a whole chapter dedicated to string and regex >>> optimisation, including a section on appending strings with the + and >>> the += operators. I won't go into details here as I'd have to retype >>> the whole section, but it's basically to do with how memory is >>> allocated for each string. Anyway, buy the book, it's good. >>> >>> Nick >>> >>> On 14 October 2011 21:25, Jess Jacobs <[email protected]> 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] >>> > >>> >>> >>> >>> -- >>> Nick Morgan >>> http://skilldrick.co.uk >>> @skilldrick >>> >>> Save our in-boxes! http://emailcharter.org >>> >>> -- >>> 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]
