At 01:50 PM 7/13/2004, you wrote:
I do not want to make any dramatic changes based on a guess of how things work.
I would like to keep functions in a CFC because I hope to build a Flash remoting interface in the future. One way to break it up would be to pull out all of the timecard functions into a single CFC stored in the server scope. Instead of referencing the "this" scope in the functions, I would reference "session.timecard."
If you put it in the server scope, you won't be able to reference the function as 'session.timecard'.
All the properties would be in the session scope and all the methods would be in the server scope. I was referring to how I would access the session *properties* from within the CFC. This is just one idea to toss around though, since it may offer no benefit. I wish I knew how CF handled things behind the scenes or how I can predict the performance of an alternate design without having to actually implement the design. If I am just storing properties inside of a CFC, it probably does not make sense for it to be a CFC.
I do know that if I make a change to the CFC file, the person has to log out then log back in to see the change, which hints at a potentially larger than expected RAM usage and object instantiation time because of the use of CFCs.
It is true that CFC changes will not be reflected in already created persistent variables. The variables (in this case a component instance) will have to be re-created. This is the case of all variables stored in the session scope.
I'm not sure how this hints ad larger than expected RAM usage. I do not expect you'll be making changes too often in a production environment.
Here is how it hints at larger RAM usage: <scenario>User 1 logs in and gets a CFC instance. One of the functions is changed in the CFC and the file is saved. User 2 logs in and gets a CFC instance.</scenario> In the scenario, user 1 would continue to get the old function until he logs out, while user 2 would get the new function. While I realize the function will not actually change in production, this behavior suggests that ColdFusion is keeping track of both functions somehow, presumably in RAM. 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. Let say the functions inside of a CFC take up 20 KB of RAM (around 400 lines of code). The use of CFCs would take up 20 KB X 10,000 = 200 MB (approx.) to store identical functions! Not only that, but the time it takes to load and unload these function surely slows down instantiate and log out time. With custom tags and cfincludes, there is only every one instance of the function. A custom tag, on the other hand, would take 20 KB X 1 = 20 KB of RAM.
---------------------------------------------------------- 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]
