> > runs longer than (I don't know) 50 ms ? > I did a test today, I have added this line...
<cfobject component="#request.componentpath#OnlineService" name="Application.OnlineService"> 200 times in the constructor of my RegistryService.cfc and I was running NetConnection Debugger with my Flash page... I saw a big difference if it's instantiated into shared scope... 250 ms compare to 40 ms every time that Flash ask for a method...when it's store into a shared scope.... compare whe it's call directly.... I understand that the constructor is only done once when it's been instantiated into a shared scope, this is where we are saving more times... but I'm not sure about the number of Methods, lines in the cfc and complexity... because I tested to add 4 times more codes and 10 times more methods... into my RegistryService.cfc... and I did not see any big difference in ms... I tested this with my facade and the real cfc... I know that the compilation is only done once... this is why I'm still storing my CFC's into the Application Scope... I'm sure that is better to instantiated only once compare to thousands and thousands of instantiation when users ask something to let say the MailService in Flash MX site... I just want to make a point that no body is talking about... but I really think that Flash MX and ColdFusion MX is the perfect match... my Flash partner has just did the login and the registration section... but I could completed all the other sections in our site... (SearchService, MailService, FavoritesService, etc).... whitout needed to have the Flash MX movie ready.... I'm in completion of 90% and she's at 25% of the creation of our site... this is understandable because Flash MX is more complex then ColdFusion MX. we can work independently. this is really great when you have two teams. and the Component Browser is the best thing for Flash and ColdFusion programmer. my hints tell everything for the Flash programmer. I feel bad when I put in the constructor the creation of application CFC instance, the Component Browser give me an error telling me that I need to use the cfapplication tag to be able to display my Component and I think I know why, it's because there is a Application.cfm in the dir C:\CFusionMX\wwwroot\CFIDE\componentutils that it's encrypted.. So we cannot modify it. to put the application tag. I would like to get an answer because I really like the Component Browser.. But when we put a constructor. is seam to be lost.. So that's why I decided to put it into all methods. instead of putting it only once in the constructor. I need Component Browser to communicate with my patterns Flash MX... this is really important I think! Stephane ----- Original Message ----- From: "Sean A Corfield" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 30, 2003 12:21 PM Subject: Re: [CFCDev] CFC Caching > On Friday, Jul 25, 2003, at 11:21 US/Pacific, cf_nut wrote: > > Okay. Can you supply some specifics about your criteria for 'heavy' ? > > Not really. It all depends on your application and how performant you > need it to be. > > > I presume that by 'construction', we mean any overheads to using the > > object, such as what's normally referred to as the 'constructor' > > code in addition to any other explicitly invoked functions. > > I mean the overhead involved in creating and initializing the instance, > prior to actually calling a method. That overhead includes: > - allocating memory & initializing a bunch of Java objects > - executing any pseudo-constructor code (between cfcomponent and > cffunction) > - under some circumstances (like the first time you create an instance > since the source code changed) there are a number of other entities > created as part of the class loading and initialization mechanism > > At the very least, constructing an instance - and this includes using > cfinvoke with a component name rather than a component instance - will > 'cost': > fixed object creation > + pseudo-constructor code > > > 500 lines in a CFC too big ? > > Irrelevant. You can have CFCs with 1,000s of lines that are still > lightning fast to create. > > > 10 functions ? > > I'm still not 100% sure of the impact the number of functions has on > creating an object. My initial tests led me to believe there was a > linear overhead but that doesn't match my understanding of how the CFML > compiler works. I need to run more tests. I'd expect inheritance to > have more of an impact. > > > 'Constructor' code that > > runs longer than (I don't know) 50 ms ? > > See above - pseudo-constructor code is definitely a factor in object > creation time. > > The real yard-stick is how many times you create a stateless CFC > instance. If you create five instances of the same stateless CFC on > every request, it doesn't match how quick it is to create, it will > definitely be faster to create one instance and reuse it. In fact, if > every single request creates an instance of the same stateless CFC, > you'll save time by creating one instance and caching it (in > application scope) and reusing it in each request. > > You can't perform that optimization on stateful CFCs because they have > their own data that is different between each instance. Cloning a > stateful CFC has at least the same overhead as creating an instance in > the first place (usually more since you end up copying in the instance > data) and what you're trying to optimize away here is the creation time. > > Sean A Corfield -- http://www.corfield.org/blog/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
