One other thing to note: if you're developing with debugging on try turning it off and seeing what happens to your performance.
In my case I built my first CFC-based and used getters/setters religiously (I'm since questioning my faith on that one). The problem is that every method call - every single little one - is logged by the debugger. I have a large instantiation process that caches a pretty complex CFC collection in the application scope. This task (done only once) results in literally thousands of methods calls (mostly for getters). With debugging on this page was taking upwards of 2 minutes. With debugging off, 10 seconds (thaes with debugging - the service - off, don't think that just using cfsetting will make a difference). So the moral is never enable debugging on a production box and keep and eye on it on your dev boxes. Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Nando > Sent: Tuesday, December 02, 2003 8:10 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Basic CFC Design Question > > Brandon, > > I'm fairly new to cfc's myself, and maybe someone else can answer this > with greater > precision, but there seems to be not much of a performance hit associated > with > invoking a CFC from within another. The big payoff comes, *i think* - this > is just my > impression because i don't have the time to get very deep into this - when > you cache > an instance of the cfc you need to invoke in a persistant scope, > remembering that the > instance data would also be cached. I don't understand all the details of > your > situation, but my naive hit on it is you could create a datasource object, > cache that > in application scope, and only reinitialize it, refreshing the instance > data, when > your application updates or adds datasources. Remember also that the > instance data > stored in the cached object could be calculated or derived from many > sources. (Like my > breadcrumb instance data for a website is derived from all the pages in > the site.) > > I think that would be much better than those includes ... someone correct > me if i'm > wrong! > > A good example to look at the performance question might be the MachII > framework. I've > read that on a production server, it takes about 20 ms for the framework > itself to > process a request. There are a substantial number of cfc's in the > framework, and much > | all of it is loaded into the app scope. Composition seems to work very > efficently. > > OH! and remember not to trust you debug output timings when looking at cfc > performance. Most of the reported execution time, 4 or 5 times more than > actual in the > case of the machii framework, is from the debugging template. > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Brandon Harper > Sent: Tuesday, December 02, 2003 11:46 PM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Basic CFC Design Question > > > Hey all, > > I'm new to the list, and haven't yet had anytime to lurk to see what this > list is all about, and I apologize if I'm asking a question which has been > answered before (I don't see a link to any archives on the CFCZone site), > or if I'm asking a question that doesn't belong here. > > For a little background about myself, my name is Brandon Harper, and I > live in Denver, Colorado. I've been developing in ColdFusion right around > the time 3.0 was released (a bit over 5 years now), I'm a Junior as > Computer Science major, and have been on computers since age 3 (I recently > turned 25), and have been programming since age 8 or so. My niche areas > of expertise beyond ColdFusion are in FreeBSD, Data Warehousing, and > general topics such as application security, and I'm starting to get a > pretty good knowledge of advanced analytics/scoring. > > Anyhow, I'm in the process of creating a "Data Services Layer" in CFC's > which all of our applications at work will eventually use. We have around > 180 different datasources of various LARGE datasources, of which the > structure of those sources changes on a regular basis. They also have to > have various security, logging, and availability parameters checked and > defined during each query for compliance reasons. These sources are > exposed to our various web products, as well as some XML Gateways which > will probably be upgraded to SOAP once this project is completed-- but the > DS Layer would sort of be the universal location that all of our products > would go to for access to our data instead of every application being > essentially a one-off as far as logging, security, and access to these > sources is concerned. > > If I were working in Java (which I'm admittedly quite green in at this > point), I'd probably setup a hierarchy similar to this and just use > "implements" to roll-up the various classes: > > +--Dataservices.class (Main Interface) > +----DataManager.class (provides logging, security, checks DSN > availability, then runs the individual query) > +-----Datasource1.class > +-- doDatasource1Query() > +-- getDatasource1RecordCount() > -----Datasource2.class > -----Datasource3.class > > .. or something like that at least. > > I'm still setting up the structure of the application, and I keep chasing > my own tail with design issues since there isn't a feature similar to > Java's multiple inheritance (with interfaces) to tie CFC's to each > other. In other words, I have fundamental issues with not being able to > extend/inherit other CFC's which are all on the same level (such as all of > what would be each CFC for each different datasources).. using extends > only works with CFC's that are in different levels in a hierarchy. > > Sorry to ramble.. on with the questions... > > 1.) I noticed that on Sean Corfields article "Software Design Patterns for > Flash Remoting" ( > http://www.macromedia.com/devnet/mx/flashremoting/articles/facades.html ), > the facade is setup to just invoke the other components via cfinvoke. The > skeptic in me assumes that this would be a pretty big performance penalty > in a busy environment, esp. when passing big sets of data between the > components since you are instantiating the CFC each time you call it? I > haven't actually worked with an application which didn't instantiate > objects into a shared scope, so I wouldn't have an idea offhand how > harmful it is. > > 2.) About the only other way I can think of offhand to do a similar > feature to doing multiple inheritance in CFC's without having to cfinvoke > each time would be to create a CFC full of cfincludes which included all > of the various files which made up the individual datasources (and > associated functions). Such as: > > datasources.cfc > - datasource1.cfm > - datasource2.cfm > > That seems like a big, messy hack to me though. Perhaps the cfinvoke > method is more painless than I think? Any other suggestions by > chance? Hopefully I'm explaining myself reasonably well? > > The main reason I'm trying to keep each datasource seperate is so that a > developer can check out a single file for each datasource if it needs to > be modified rather than checking out a CFC which contains all of them > which more than one person might need to use at the same time. > > Thanks, > > - Brandon > > -------------------------- > http://booms.net > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail- > archive.com/[EMAIL PROTECTED] > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail- > archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
