CODEWITHSUNDEEP
asp.net-mvcperformance
user60456
user60456

Reputation:

Will a ConcurrentDictionary over the HttpRuntime.Cache hurt me in the long run?

I am trying to squeeze out any little bit of perf possible, and as such I was looking at a custom ViewLocationCache.

The default one stores the lookup in the HttpRuntime.Cache, and if possible, I wanted to try to avoid the overhead associated there. Mainly because I have several views that call Html.RenderPartial in a loop.

What I thought about doing was using a ConcurrentDictionary instead. I have looked through the MVC source, and I can't see nor think of a reason this would be bad. I deploy to Azure, so the AppDomain is guaranteed to get reset on a deploy, and I don't need to worry about bad hits.

Am I missing something painfully obvious as to why I shouldn't do this?

//fastCache is a static ConcurrentDictionary<string, string>
public string GetViewLocation(HttpContextBase httpContext, string key)
{
    return fastCache[key];
}

public void InsertViewLocation(HttpContextBase httpContext, string key, string virtualPath)
{
    fastCache[key] = virtualPath;
}

Upvotes: 1

Views: 716

Answers (1)

Darin Dimitrov
Darin Dimitrov

Reputation: 1038800

HttpRuntime.Cache gives you fine grained expiration policy that could be configured which you don't get with the concurrent dictionary. For example if your server starts running low on memory based on the priority you have defined for your items it will expire them, whereas the concurrent dictionary will continue to grow until your application blows with out of memory errors. But if you have determined that HttpRuntime.Cache is somehow penalizing your application performance (which would be pretty surprising) it seems a valid reason to try to find an alternative. Just don't forget that there's much more to HttpRuntime.Cache than a simple thread safe hashtable.

Upvotes: 3

Related Questions