I've been having troubles posting to the list (mess up my end with incoming and outgoing servers for different accounts), but I'm not at all sure this is true.
Imagine you are returning a collection of users to display on the page - let's say 100 users. Now let's assume that each user has LOTS of getters and setters and that you've made a decision to provide them as a rich user API to hide any implementation details (so you have a User.getBillingPhone() rather than a User.getBillingAddress.getPhone()). Lets say there are 50 properties, which gives us 100 getters and setters. So, with oMM(), we have to create 100 objects and then use oMM() to access/mutate properties. Without it, in Adobe ColdFusion we're gonna have to create 10,000 objects as each method is compiled into its own little object. I gotta believe that there is at least a chance that the performance penalty of creating an additional 9,900 objects could in some circumstances outweigh the extra processing time for the dynamic evaluation of the getters and setters. Best Wishes, Peter On Jan 31, 2009, at 9:04 PM, Brian Kotek wrote: > Yes, I'm positive. Having the functions compiled to Java at compile > time will ALWAYS be faster than dynamically evaluating the function > at runtime. Though the fact that it's slower isn't the main reason I > prefer real getter and setter functions and I doubt the difference > is very large unless the oMM is performing a great deal of > processing or metadata parsing. > > On Wed, Jan 28, 2009 at 1:33 PM, Henry <[email protected]> wrote: > > Are you guys certain that oMM will be always less efficient? Didn't > creation (and attaching) methods into an object is also expensive in > CF8? Since beans needed to be created all the time, maybe the cost of > creation of methods will offset the slightly inefficient oMM? I guess > performance should not, in theory, affect how we construct our code, > but at some point it does. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
