Should I use the static cached ResourceManager or a new instance for each web request? Does it matter?

Question

What, if any are the performance (or other) implications of creating a new .NET ResourceManager on every request with new ResourceManger(myResourceType.FullName, myResourceType.Assembly) vs using the "cached ResourceManager instance" in the .Designer.cs generated class (MyResourceType.ResourceManager)?

I am working in the context of a ASP.NET MVC 3 application using .resx files.

Edit: I am interested in implications beyond the cost allocating memory for the new object.

Edit: Looking at the MSDN documentation for ResourceManager.ReleaseAllResources, it states that:

This method will shrink the working set in a running application. Any future resource lookups on this ResourceManager will be as extensive as the first lookup, since it will need to search and load resources again.

This seems to imply that the initial opening of the resource set is expensive, which suggests to me that creating a new manager on each request could be expensive. However, the docs don't suggest a best practice with regard to the lifetime/scope of resource managers.

Answer 1

I did some primitive profiling (using MiniProfiler) of the difference between using a cached manager (I used reflection to find the static cached manager for each resource type) and using a new manager for each key access. The results suggested that the new manager took about 45 times as long, which suggests to me that there is a real performance benefit to using the cached manager approach. However, both approaches were so fast that the difference probably doesn't matter much in practice.