HttpRuntime.Cache vs. HttpContext.Current.Cache

Here's a development tip I came across on one of the ASP.NET discussion lists I'm on, at AspAdvice.com.

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.