In truth, I believe that I was the one who originated the test for these minor speed differences 'back in the days'. The reasoning was actually quite simple, different pieces of CF were coded internally in different ways. This could most readily be seen in the massive speed difference between IIF and CFIF (a difference that does not exist in CFMX). Knowing that things are coded differently, it was logical to think that the code for a CFSET might be different than the code for a CFSCRIPT. Each CFSET would be its own tag to be parsed one by one where all of the elements of a CFSCRIPT would be parsed together. This was proven out with a test showing that 3 or more sets in a CFSCRIPT started to show a savings over 3 or more CFSETs in a row. Were these things really important? No. The speed savings were rather minor and no site was really hit often enough to really gain or lose from the different code. I did it just because it was an intellectual exercise. The same as these posts. If we know how CF reacts to pieces of common code we can: 1. Dispel myths about CFMX 2. Note changes from previous versions 3. Get to what is really needed for good code. As Dave Watts said in his post: "Meanwhile, I've seen far too many CF developers neglect the very foundations of adequate web application performance - caching, database optimization, server tuning, and did I mention caching?" I agree 100% with my main additions being in the field of standardization (personal or community), commenting, cleanliness, and all around tightness of code. Do it right, do it tight and you'll have no problems.
> It's really interesting - to me - to see such attention to such 'small' > language details in terms of performance. ColdFusion is the only > language I've ever worked in where such small details made such big > difference in speed... and now it seems it is only historical (which is > code: CFML now behaves more like other languages). > > On Thursday, Dec 5, 2002, at 22:07 US/Pacific, Michael Dinowitz wrote: > > 1. There is no speed difference between using CFSET to set a variable > > and using > > CFSCRIPT to do so. This is true for setting a single variable as well > > as setting > > multiple variables. I prefer to use CFSCRIPT when setting multiple > > variables as > > I think it looks cleaner, but the choice is yours. It's all style. > > I'm amazed there was a speed difference before MX. I would have classed > that as a bug in CF5. I agree on what looks cleaner. > > > 2. There is no difference between setting a variable to the value of > > another > > variable with or without pound signs. The following all work at about > > the same > > speed. > > <CFSET name=url.name> > > <CFSET name=#url.name#> > > <CFSET name="#url.name#"> > > Again, I'm stunned that CF5 treated these differently - the compiler > can statically determine these are identical and should generate > identical code. > > > Again, the issue is proper formatting and style. This means that the > > first CFSET > > is the better one syntactically. > > Agreed. > > > 3. Setting a variable to a combination of text and dynamic data can be > > done by > > setting the dynamic data within the string OR by concatenating it all > > together. > > Both are about the same speed. > > <CFSET time="The time is now "&timeformat(now())&" on > > "&dateformat(now())&". > > Your index is "&i> > > <CFSET time="The time is now #timeformat(now())# on > > #dateformat(now())#. Your > > index is #i#"> > > Again, the compiler can figure this out so I'm surprised there was a > speed difference before. > > > This is where things get tricky style wise. According to older styles > > and most, > > if not all of the authors (myself included), the first style is the > > better one. > > I prefer the second style, even tho' the first style is more like other > languages I've used. I find CF's in-string evaluation to be very > elegant (and I'm glad that in MX there's no performance penalty!). > > > Bottom line is that almost anything done in the past to make a CFSET > > faster is > > now obsolete and the only reason to really use one type of CFSET over > > another is > > style and readability. > > Which is definitely good news! And it supports my view that readability > is (generally) more important than performance. Code for readability > and if - and only if - you find you have a performance problem, profile > it and fix it. > > Sean A Corfield -- Director, Architecture > Web Technology Group -- Macromedia, Inc. > tel: (415) 252-2287 -- cell: (415) 717-8473 > aim: seancorfield -- http://www.macromedia.com > An Architect's View -- http://www.corfield.org/blog/ > > Introducing Macromedia Contribute. Web publishing for everyone. > Learn more at http://www.macromedia.com/contribute > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com
