I'm guessing here, but it could do with the fact that case 3 has to create 2 string primitives where as case 1 creates 1 primitive and uses a pointer to an already created primitive (which I presume is a cheaper operation).
----- [email protected] / http://andrew.hedges.name/ On Sat, October 15, 2011 11:37 am, Jess Jacobs 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]
