A method call is more expensive than a variable reference, but the encapsulation the method provides is worth it in almost all scenarios. It's very unlikely that this would grow to a bottleneck since the more such operations you have, the more other stuff you're doing in the request (most likely). Only careful load testing will indicate if there's a problem, but I'd say you're safe to assume there won't be.
A few request scoped objects is all you'll need in most cases. Most of your objects (including all those you listed in your email) should be instantiated into the application and/or session scopes for peristance across requests. That'll speed things up because of massively reduced instantiation overhead, and let you do stuff like caching. The number of lines of code in an object will affect instantiation of the CFC's FIRST instance (when it's read from disk), but not after that. The number of methods will affect instantiation of all instances (but exceedingly little). Again, until careful load testing has illustrated an explicit issue, don't even consider it to be a potential issue. The first and last items are saving you a couple ms tops, per request, but the middle item could well be saving you hundreds of ms per request. cheers, barneyb On 1/20/06, Peter Bell <[EMAIL PROTECTED]> wrote: > > Hello All, > > Does anyone have any kind of information on the relative expense (processing > wise) of different operations? For example, assuming a user object has been > instantiated, how much more processing does it take to getUserFirstName() > (assuming it is just a "return THIS.FirstName") versus just using dot > notation against the THIS scoped variable for the object? > > If you have a few hundred such operations as page of processing a page > request, would the choice have any substantive affect on application > performance? > > I know there are guides on CF best practices for performance (avoid > evaluate, use list compare instead of multiple string comparisons, etc.) but > I can't find a good guide to the relative cost of OO operations in CF that > would help to ensure a design would have a decent shot at being performant. > > Also, while I know it is extremely broad, in general what range of number of > request scoped objects mught you instantiate in a common page request for a > "well architected app"? I'm assuming that it would be common for a > sophisticated page request to instantiate 10-50 objects between the > controller, facades, domain objects, compositional objects and the DAL. Is > that a fair heuristic? > > Finally, does the physical size of an object (the number of lines of code > across all of the methods) have any substantive effect on initialization > performance (does the entire object get loaded into memory or are the > methods loaded into memory one at a time? For example, if you have an object > with 20 methods each with 500 lines of code where any given page request may > call only one or two of the methods, would you consider abstracting some of > the methods into separate objects to cut down on object instantion time? > > I want to clarify, I'm not trying to shave page processing from 45 to 18ms, > I'm just trying to make sure that pages with minimal db and file system > access don't end up taking 300-400ms. > > Any thoughts much appreciated! > > Best Wishes, > Peter -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
