RE: [CFCDev] Expense of Operations?

[Nando]

Jerry,   1) You can / need to rearchitect your app so that you only instantiate CFC's per request when absolutely necessary. I'd suggest persisting a Factory (or several Factories) as singletons and have them take care of returning instantiated instances of your CFC's. I first got this from studying the Mach-II framework code. Model-Glue also does this.   2) You can't rely on the debugging output to gauge straight-line cfc performance. For CFC's, the bulk of the reported timings are from the time it takes for the debugging template to calculate the timings, not from the CFC's execution. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jerry Ela Sent: Sunday, January 22, 2006 12:22 AM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Expense of Operations? A timely question.  I have a cfc based app and am being killed by the time it takes to instantiate the cfcs.  I've moved anything I could to application or session scope, but have a lot of cfcs that need to be instantiated on a per request basis.  I beginning to think I should change my cfcs into function libraries that modify external data structures  instead of objects that manage instance data so I don't have to take the instantiation penalty.  I know there are a lot of cfc based frameworks in use and a lot of cfc based high volume websites that are cfc based, which would tend to say that using cfcs isn't a totally crazy idea.  What kind of a hit do you see from instantiation as compared to other operations?  How many cfc instantiations is reasonable for a request?  Are there server config issues I should be looking at as a more likely cause of problems than the fact that I'm using cfcs? Peter Bell wrote: Hello All,   Does anyone have any kind of information on the relative expense (processing wise) of different operations? For example, assuming a user object has been instantiated, how much more processing does it take to getUserFirstName() (assuming it is just a "return THIS.FirstName") versus just using dot notation against the THIS scoped variable for the object?   If you have a few hundred such operations as page of processing a page request, would the choice have any substantive affect on application performance?   I know there are guides on CF best practices for performance (avoid evaluate, use list compare instead of multiple string comparisons, etc.) but I can't find a good guide to the relative cost of OO operations in CF that would help to ensure a design would have a decent shot at being performant.   Also, while I know it is extremely broad, in general what range of number of request scoped objects mught you instantiate in a common page request for a "well architected app"? I'm assuming that it would be common for a sophisticated page request to instantiate 10-50 objects between the controller, facades, domain objects, compositional objects and the DAL. Is that a fair heuristic?   Finally, does the physical size of an object (the number of lines of code across all of the methods) have any substantive effect on initialization performance (does the entire object get loaded into memory or are the methods loaded into memory one at a time? For example, if you have an object with 20 methods each with 500 lines of code where any given page request may call only one or two of the methods, would you consider abstracting some of the methods into separate objects to cut down on object instantion time?   I want to clarify, I'm not trying to shave page processing from 45 to 18ms, I'm just trying to make sure that pages with minimal db and file system access don't end up taking 300-400ms.   Any thoughts much appreciated!   Best Wishes, Peter  ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org