The better way to reference a component

[Aegis_Kleais]

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">

[Adam Cameron.]

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

[Aegis_Kleais]

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.

[Adam Cameron. · Accepted solution]

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

[Aegis_Kleais]

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.

[-__cfSearching__-]

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.

[Aegis_Kleais]

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?

[-__cfSearching__-]

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.

[BKBK]

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. 

[Adam Cameron.]

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

[BKBK]

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.

[BKBK]

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.