RE: CFSET in CFMX
It's funny you should bring caching up, Dave. What do you make of this error message? Retrieval of cached query failed The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (74:1) to (74:175) in the template file C:\WEBSITE\HTDOCS\SMARTER\QUERIES\QRY_SEARCHHANDL_ORIGINAL.CFM. Where the cached query at line 74 is: SELECT ID FROM afulltable (nolock) WHERE City = '#REQUEST.GetClientDataCity.City#' AND ( CONTAINS(fulltext,' #VARIABLES_SEARCHTERM# ')) WHERE CONTAINS(fulltext,' #VARIABLES_SEARCHTERM# ') best, paul At 02:37 AM 12/8/02 -0500, you wrote: >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? ~| 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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
Re: CFSET in CFMX
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. > > > > > > > > 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. > > > "&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
RE: CFSET in CFMX
> -Original Message- > From: Dave Watts [mailto:[EMAIL PROTECTED]] > Sent: Sunday, December 08, 2002 2:38 AM > To: CF-Talk > Subject: RE: CFSET in CFMX > > > > 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). > > In my experience, which may run contrary to others', these > small language details didn't generally make much difference > in CF 5 or previous versions, actually. For some reason, > though, CF programmers have tended to focus on them to a > degree way out of proportion to their actual impact on the > average web application. I'm not sure why this is; I think it > might have to do with the degree of ambiguity and looseness > in CFML. I've worked with quite a few CF applications, > though, and I haven't yet encountered a situation where these > sorts of things were the performance bottlenecks within the > application. So, when I see these sorts of things, they bring > to mind debates about how many angels can dance on the head of a pin. I agree - but I also think that this focus on the ridiculous details is also a tangental sign of CF's community health. It seems to me that any community that deeply, truly, honestly loves the thing it's gathered about starts to "get into the nitty-gritty" like this. Bascially when the "big news" isn't there (new versions, etc) a dedicated community goes into the details with a force. You see the same thing in any fandom: science fiction (think of "Star Trek" and "Star Wars"), hardware (whether it's cars or computers - everybody wants that extra performance even if it's only on paper), music (even here somebody arguing vinyl vrs CD?), or what have you. I honestly don't think that it has anything to do with the way CFML is constructed - I really think that it's just another excuse for this community to keep on talking with each other. That being said I've done a lot of (past) work on some of this stuff... And pretty small changes could make for large difference. However the point remains firmly in place that these differences are only noticable in isolation and within a larger application are almost never great enough to cause problems. However there's also always something... Something that runs every template, something that the whole app hinges one... And that something (whatever it is) is often worth tweaking out as much as possible. > 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? True, very true. Of course that's what freelancing is there to fix... Did I mention that I'll be available for new clients at the first of the year? ;^) Jim Davis (Who is actually very serious about that last bit... www.depressedpress.com) ~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
RE: CFSET in CFMX
> 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). In my experience, which may run contrary to others', these small language details didn't generally make much difference in CF 5 or previous versions, actually. For some reason, though, CF programmers have tended to focus on them to a degree way out of proportion to their actual impact on the average web application. I'm not sure why this is; I think it might have to do with the degree of ambiguity and looseness in CFML. I've worked with quite a few CF applications, though, and I haven't yet encountered a situation where these sorts of things were the performance bottlenecks within the application. So, when I see these sorts of things, they bring to mind debates about how many angels can dance on the head of a pin. 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? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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
RE: CFSET in CFMX
Well, using CFSCRIPT, the first was always unbelieveably slow. > -Original Message- > From: Michael Dinowitz [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 05, 2002 11:39 PM > To: CF-Talk > Subject: Re: CFSET in CFMX > > > The first or the second? I and others had seen the second taking > more time. In > the first CF is putting a string together from pieces. In the second CF is > parsing the string once to find CF elements and then evaluating them. An > additional bit of work. > > > > Both are about the same speed. > > > > > "&dateformat(now())&". > > > Your index is "&i> > > > > > > > Yay! The first syntax was incredibly slow in previous versions > of CF. So > > slow, in fact, that it was just about the only line code > optimization I ever > > did, because it could be hundreds of times slower. > > > > > > > ~| 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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
Re: CFSET in CFMX
- Original Message - From: "Michael Dinowitz" <[EMAIL PROTECTED]> > Your index is "&i> > > This is where things get tricky style wise. FWIW, I've settled on the latter. In Homesite+ I have strings set to be light blue and italicised. So with the second one I can see the whole string as "one" - much easier to scan. Plus, with the first one, the colour-coding for character entities (black italicised - which I keep) means that concatenating with ampersands displays bits of the string in an ugly, hard-to-read way. You can space them out, but then it's still harder to scan when debugging than the second technique. Gyrus [EMAIL PROTECTED] work: http://www.tengai.co.uk play: http://www.norlonto.net PGP key available ~| 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 Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
Re: CFSET in CFMX
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. > > > 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. > "&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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
Re: CFSET in CFMX
The first or the second? I and others had seen the second taking more time. In the first CF is putting a string together from pieces. In the second CF is parsing the string once to find CF elements and then evaluating them. An additional bit of work. > > Both are about the same speed. > > > "&dateformat(now())&". > > Your index is "&i> > > > > Yay! The first syntax was incredibly slow in previous versions of CF. So > slow, in fact, that it was just about the only line code optimization I ever > did, because it could be hundreds of times slower. > > > ~| 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 Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
RE: CFSET in CFMX
> 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. > "&dateformat(now())&". > Your index is "&i> > Yay! The first syntax was incredibly slow in previous versions of CF. So slow, in fact, that it was just about the only line code optimization I ever did, because it could be hundreds of times slower. ~| 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 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
