Yeah, that seems logical. Excellent. Thanks! ======================== Jess Jacobs [email protected] flavors.me/akisma - music, sound design, code.
On Fri, Oct 14, 2011 at 1:02 PM, Andrew Hedges <[email protected]> wrote: > 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] > -- 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]
