Original question:
Is there a difference in accessing the Cache of an application when calling HttpRuntime.Cache vs. HttpContext.Current.Cache? I "think" I remember reading about a difference in the two a few years ago, but I don't remember the specifics. This assumes that I am within a web application.
Answer from Rob Howard:
HttpRuntime.Cache is the recommended technique.
Calling the HttpContext does some additional look-ups as it has to resolve the current context relative to the running thread.
I use HttpContext.Current in a lot of the code I write too; but touching it as little as possible. Rather than calling HttpContext.Current repeatedly it's best to hang onto a reference and pass it around (when possible).
If you're in a component HttpRuntime.Cache is still the recommendation.
That said... the differences in performance are not going to be noticeable in 99% of the applications many of us write. The cases where it is going to matter is the 1% (or less) where you're trying to squeeze every last drop of performance out of you system. But this is a *minor* performance tweak, e.g. eliminating a database call, web service call or other out-of-process call in the application is definitely a better place to spend optimizing code.
For example, if you have 5 database calls in a particular code path reducing (or even optimizing) the queries is a much better use of time.
So yes, HttpRuntime.Cache is recommended but likely won't make a difference in most applications.
Another reply from James Shaw at CoverYourASP.NET:
I discovered another *great* reason to use HttpRuntime too, when writing my unit tests - HttpRuntime.Cache is always available, even in console apps like nunit!
http://www.coveryourasp.net/UnittestingandCaching
I never use HttpContext anymore, even in class libraries.
from: http://weblogs.asp.net/pjohnson/archive/2006/02/06/437559.aspx