Copy link to clipboard
Copied
In general, when something can be used by all visitors in 1 application, I store that into the application scope for quick memory-based performance.
My application has a component called "dao.cfc" (handles data access) and quite literally every user on every request is going to use that component at least once per load.
Is there any performance boost in storing a copy of the dao.cfc into the application scope vs. just pathing out to it as it is needed, ie:
IN APPLICATION SCOPE (the dao component is stored in the application.com structure)
#application.com.dao.functionName( args, args, etc. )#
vs.
AS NEEDED PER REQUEST
<cfinvoke component="app.com.dao" method="functionName" arg="value" etc="etc">
Yes the CFINVOKE call has to create a new object every time (even if it's discarded automatically once you're done), whereas with the application-scoped approach, you're just creating the one object.
Creating objects has a fairly high overhead compared to most other in-memory operations in CF.
If you have a stateless object - which a DAO ought to be - then there's no reason to keep creating new instances of it every time you need to call one of its methods.
--
Adam
Copy link to clipboard
Copied
Well yeah: obviously creating a transient object any time you need one is going to have overhead that reusing the same object is not going to have.
--
Adam
Copy link to clipboard
Copied
But I'm using them both the exact amount of times. Are you saying that:
#application.com.dao.functionName( args, args, etc. )#
#application.com.dao.functionName( args, args, etc. )#
#application.com.dao.functionName( args, args, etc. )#
will always be faster than
<cfinvoke component="app.com.dao" method="functionName" arg="value" etc="etc">
<cfinvoke component="app.com.dao" method="functionName" arg="value" etc="etc">
<cfinvoke component="app.com.dao" method="functionName" arg="value" etc="etc">
So the amount of effort it takes for CF to store the dao into the application scope and then call it for all users is less than each user invoking a component as needed.
Copy link to clipboard
Copied
Yes the CFINVOKE call has to create a new object every time (even if it's discarded automatically once you're done), whereas with the application-scoped approach, you're just creating the one object.
Creating objects has a fairly high overhead compared to most other in-memory operations in CF.
If you have a stateless object - which a DAO ought to be - then there's no reason to keep creating new instances of it every time you need to call one of its methods.
--
Adam
Copy link to clipboard
Copied
OK, then for any component that I feel is called across every user or at least once per request, it would be best I instantiate it into the application scope.
For components that offer functionality that is called as needed (especially if called less often than once per request), I can invoke it manually as needed. Thanks.
Copy link to clipboard
Copied
for any component that I feel is called across every user or at least once per request, it would be best I instantiate it into the application scope.
As long as they are stateless components, yes.
Just be sure you are vigilant about var/local scoping all function variables, or you may discover weird threading bugs you did not know existed in the code.
Copy link to clipboard
Copied
By a "stateless" component, you mean one that isn't associated wtih like a specific user or object, right?
Like if the DAO is just being used as a utility to any and all queries, it's perfect to use, but the moment I need to do something associated with an instance of an object, it's better those functions be called as needed, right?
Copy link to clipboard
Copied
By a "stateless" component, you mean one that isn't associated wtih like a specific user or object, right?
Right. It is not tied to a specific user, request, etcetera, but more importantly it does not maintain information beyond the end of a function call.
Copy link to clipboard
Copied
The fact that a component is stateless in insufficient reason to store it in application scope. This is particularly relevant for an instance of the DAO.
One would expect that the DAO connects to the database. In that case, it will send queries to the database and receive result sets. Were the DAO in application scope, it might likely imply that one user request keeps other requests waiting.
Copy link to clipboard
Copied
One would expect that the DAO connects to the database. In that case, it will send queries to the database and receive result sets. Were the DAO in application scope, it might likely imply that one user request keeps other requests waiting.
Object instances are not single-threaded. This is not a concern.
--
Adam
Copy link to clipboard
Copied
Adam Cameron. wrote:
One would expect that the DAO connects to the database. In that case, it will send queries to the database and receive result sets. Were the DAO in application scope, it might likely imply that one user request keeps other requests waiting.
Object instances are not single-threaded. This is not a concern.
That's the point. Particularly, DAOs or parts of DAOs usually require exclusive locks to synchronize read/write operations on the database.
Copy link to clipboard
Copied
BKBK wrote:
Adam Cameron. wrote:
One would expect that the DAO connects to the database. In that case, it will send queries to the database and receive result sets. Were the DAO in application scope, it might likely imply that one user request keeps other requests waiting.
Object instances are not single-threaded. This is not a concern.
That's the point. Particularly, DAOs or parts of DAOs usually require exclusive locks to synchronize read/write operations on the database.
Forget it. I could find the converse of an argument that makes my point redundant. Before you put a DAO in the application scope, ensure that it is stateless, that is, multithreaded and immutable. If it isn't, then don't put it in the application scope.