RE: CF performance tuning: CFTRY/CFCATCH vs CFERROR? What about e xcessive CFOUTPUTs?
Is there any definitive info on whether it is more efficient to put a CFTRY around an entire page's contents, with a CFCATCH at the end to trap errors, or to simply have a CFERROR page specified in application.cfm (and only use CFTRY/CFCATCH in specific pieces of code that might need special error handling procedures)? In other words, what is the performance cost for code that is executing within a CFTRY block? I'm interested in this because the CF server that I've just recently started working with seems to be having periodic performance problems (still trying to determine what periodic actually means), and noticed that a lot of the application's pages have a single CFTRY around them. I think you're asking the wrong question. I seriously doubt whether there are any significant performance implications one way or the other. However, wrapping a CFTRY around a page is bad, bad, bad! That's not what it's for - that's why we have CFERROR. Wrapping a CFTRY around a page prevents you from using CFTRY usefully within that page. The purpose of exception handling is to let you identify and trap specific problems, and provide specific solutions for those problems. When you wrap the entire page in CFTRY, your problem could be on line 2 or line 200. Plus, it means that you have to manage generalized error handling within each page, which is unnecessarily complicated. I've also noticed excessive use of CFOUTPUT tags. Is it worth consolidating these to help performance? I've seen as many as 5 in a block of code that's only 30 lines long, where only 1 was needed. I doubt you'd see any significant difference here, either. What about excessive # marks? It makes me crazy to see code like cfif #somevariable# eq yes ... But does that also make CF crazy? I'd think that this goofiness would not actually filter down to the Jrun code that actually executes, right? I don't think this makes any significant difference either. Any good MX7 performance/tuning papers running around? I checked on the macromedia website, and with google, but only found info on older versions. To the extent that those older versions address CFMX 6.1, they should still be largely valid for 7. There isn't that much difference, really. In general, you're far more likely to improve performance by examining data access and caching more closely. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:227954 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: CF performance tuning: CFTRY/CFCATCH vs CFERROR? What about e xcessive CFOUTPUTs?
On 12/29/05, Dave Watts [EMAIL PROTECTED] wrote: However, wrapping a CFTRY around a page is bad, bad, bad! That's not what it's for - that's why we have CFERROR. As obsessed as I am about error handling, it unfortunately took me a long time to learn this, and I am still pulling try/catch statements out of old code I come across. I did it for years. With that in mind... Wrapping a CFTRY around a page prevents you from using CFTRY usefully within that page. Actually you can nest try/catch (wrap whole page, with individual code blocks wrapped inside of that) and its not a problem, although as you say its a dumb thing to do, once you know better. When you wrap the entire page in CFTRY, your problem could be on line 2 or line 200. Yes indeed, but cfcatch-scope variables will tell you precisely where the error occurred, and why, just like you'd get with an error-scope message. Pretty sure you even get a stack trace so you can drill down to the include or module that *really* caused the problem. -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:227957 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: CF performance tuning: CFTRY/CFCATCH vs CFERROR? What about e xcessive CFOUTPUTs?
Actually you can nest try/catch (wrap whole page, with individual code blocks wrapped inside of that) and its not a problem, although as you say its a dumb thing to do, once you know better. Sure, you can do that. But it adds unnecessary complication to error handling, and can cause some odd problems. For example, if you write an exception handler that doesn't know what to do with the exception it's caught, it should kick the exception to a higher level. If that higher level is your page-wide exception handler, it might not be able to respond in an especially useful manner, since it's written to deal with anything that happens within the entire page. Yes indeed, but cfcatch-scope variables will tell you precisely where the error occurred, and why, just like you'd get with an error-scope message. Pretty sure you even get a stack trace so you can drill down to the include or module that *really* caused the problem. Yes, the exception itself will provide descriptive information, which is good to have after the fact. But one of the primary purposes of exception handling is to deal with problems as they occur, and to do this you have to have a pretty good idea in advance of what kinds of problems you can expect. Wrapping an entire page in CFTRY indicates that you don't actually have any idea what's going to go wrong, and can't really do anything other than report the exceptions it receives. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:227958 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
