Mike, Another take on this CFC size issue you might want to consider is that for "most people", it's probably a lot easier to maintain (and certainly modify) an app with smaller, highly cohesive CFC's. Any 2000 line file can attest to this. I know "small" is certainly a matter of degree, but being an totally inexperienced OO guy, i took what i thought was going to be the easier route, and built somewhat larger objects to start with, but less of them. I didn't quite get how to fashion the object relationships into a working model if i broke everything down into bite sized chunks of responsibility. And i'm still working on understanding patterns well enough to do that (in between all the other things i need to take care of).
BUT ... after working with it for a few months, i see very clearly that i have an app whose object model isn't nearly as easy to maintain or change or add functionality to as it could be. I'm staring at the importance of cohesion, "do one thing and do it well". But to reach that goal, one needs to understand how to form all those isolated, encapsulated bite-sized chunks into an object model that functions as an orchestra. And that takes time and experience - which is the other thing i'm staring at (the lack of, actually, and how to make up for that). So what i've found is that it's more challenging or difficult (depending on your degree of experience - for me it's still difficult) to build a app with highly cohesive objects - small ones, but it's a lot easier to maintain and modify them. So at present, i'm working on rebuilding the object model i'm working with, and this time i'm breaking it down as best i can. Which means if an object is too big for me to grasp in a few moments what it's responsible for on a conceptual level, i'm going to stare at it for awhile and see how i might break it down into smaller, more cohesive chunks, and work those chunks into a modified model. As to your research and questions about instantiation and performance, great stuff to look into ... but again, a well designed object model will take that into account if needed. Case in point, the Mach-II framework, which caches itself and many or most of the objects you use in the app you build with it into the application scope, resulting in excellent performance - perhaps unachievable in any other way. Which reminds me ... don't trust the debugging data when looking into CFC performance - the debugging itself takes time, sometimes up to 5 times the actual if your model is somewhat complex. But perhaps you know this already. In fact, perhaps you know all of this already .. but i felt it worth restating, if only for myself. Nando -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mike Chabot Sent: Tuesday, July 13, 2004 10:17 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] CFC size > > So lets say 10,000 > > sessions are open at once, which is very reasonable for this application. > > That means that 10,000 copies of every function that is in the CFC now > > reside in RAM, even though every function is identical. > >No, only *one* copy of each function is present in memory. Sean, Thanks for the reply. I will assume your answer is correct until proven otherwise. Based on your response I would suppose that, as long as you are not the first person to log in after the CFC changes, it should not matter how many functions I cram into a CFC from a scalability perspective. If I am the second person to log in, the functions in my CFC are merely pointers to functions that are already present in the session scope, so should not take any appreciable amount of time to load or parse. Some very brief testing: With approx. 900 lines of code in the CFC, the first instantiation takes around 1 second, and each subsequent instantiation takes 0.06 seconds. With approx. 4300 lines of code (by making copies of a big function), the first instantiation takes around 5 seconds, and each subsequent instantiation takes 0.07 seconds. Thank you, Mike Chabot ---------------------------------------------------------- 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]
