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
----------------------------------------------------------Peter
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]
