Coming in a little late too -- but we've been using the var local = StructNew() code for quite some time now. I initially did some performance testing and found the overhead to be marginal at best.
I agree with Brian, I haven't found too many times where I've need to loop over things 1000 or more times. Where I've had to do this, I've found the biggest problem to be time in executing the method call itself. For instance, using the addNumbers method takes 1781ms (1610ms using 'var') and 141ms using inline code.. I had to convert some of our code to use inline logic instead of modular methods because the component was built for performance (e.g. generates a report). Darryl Lyons Assistant Applications Development Manager IT Operations Brisbane -+- ABN AMRO Morgans Limited Level 29, 123 Eagle Street BRISBANE QLD 4000 PH: 07 333 44 800 FX: 07 3834 0800 [EMAIL PROTECTED] wrote on 11/07/2005 11:33:07 PM: > > You're right, this is very contrived and is an extreme case, but I > agree in such an edge case you would not want to create an > additional struct (even though I would argue that the performance > impact is not very great when you're already creating hundreds of > thousands of separate String instances for the var decalred > variables.) I've built a lot of large applications have have rarely > run into a situation where I need to execute a loop even 1000 times, > let alone 100,000 times. In the vast majority of cases, using a > local struct has extremely limited impact on performance. And for > me, the benefit of seeing that every local variable is truly local > is what I am really after anyway. It's so easy for people to forget > to var scope everything that in my opinion this performance impact > outweighs the danger of variables slipping into the variables scope. > > Regards, > > Brian > > On 7/8/05, Roland Collins <[EMAIL PROTECTED]> wrote: > The problem with the "local = StructNew()" method is there are times > when it can cause problems. Take this code for example: > > <cffunction name="addNumbers" result="numeric"> > <cfargument name="num1" type="numeric"> > <cfargument name="num2" type="numeric"> > > <cfset var local = StructNew()> > > <cfset local.result = num1 + num2> > > <cfreturn local.result> > </cffunction> > > Now yes, this is contrived, and I know I could return the result > directly – it's just for the sake of the example. Now pretend you > have some code that calls this in a loop: > > <cfloop from="1" to="100000" index="i"> > <cfset mySum = addNumbers(i, 100)> > </cfloop> > > Well guess what – you just added the overhead of 100,000 unnecessary > object creations. You've also added 100,000 StructInsert() calls > (the cfset local.result statement does it implicitly). Not only > does this directly hurt the performance of the code, it also affects > the underlying server processes. That's now 100,000 additional > structs that have to be Garbage Collected!!! > > Anyway, in this case, you obviously would never want to use the > local = StructNew() method, and I run into too many other examples > of this type of code that make it undesirable to use. Not to mention I _like > _ seeing all of my variables declared up front. > > /.02 > > Roland > To unsubscribe from this email please forward this email to [EMAIL PROTECTED] This email message is confidential and may be privileged. Unauthorised use, copying or distribution of any part of this email including attachments is prohibited. If you are not the intended recipient please forward the email to [EMAIL PROTECTED] and delete the original. ABN AMRO Morgans Limited and its associates hold or may hold securities in the companies/trusts mentioned herein. Any general advice included in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on the advice, you should consider its appropriateness or discuss with one of our investment advisors. To the extent permitted by law we exclude (and where the law does not permit an exclusion, limit to the extent permitted by law) all liability for any direct, indirect and consequential costs, losses, damages and expenses incurred in any way (including but not limited to that arising from negligence), connected with any use or access to this email or any reliance on information contained in this email or any attachments. ABN AMRO Morgans Limited (ABN 49 010 669 726 AFSL 235410) A Participant of ASX Group A Principal Member of the Financial Planning Association
