Performance Overheads when Using Resource Files (.resx)

Question

Note, I am aware of the following questions on this topic:

1. Are there any performance issues or caveats with resource (.resx) files?

2. Are string resources (.resx) properties kept in memory?

et al. However, I don't find any of the answers in these questions satisfactory (they are not concrete enough).

I am also aware of the MSDN pages on this topic, but these also seem to skimp on the technical information regarding the overheads of using resource files.

---

My predicament is that we are about to embark on the localisation of a reasonably large sized WinForms application. My concern at this stage is about the performance of accessing resources from a .resx file from within a nested loop for example. Currently for the small part of the code we have localised (Column Names, Row Headers etc. for DataGridView etc.) we are cashing the resources in global variables of the relevant class and using those.

How are resources from the .resx accessed (are they included in the assembly at compile-time?) and is there a performance benefit from cashing those resources and using global variables for access?

Answer 1

String resources are cached in memory. Look at the code that's generated in "Resources.Designer.cs".

It uses a System.Resources.ResourceManager, and this does caching of the strings.

Also note this ResourceManager constructor. It mentions that you can change caching strategy:

This constructor uses the system-provided ResourceSet implementation. To use a custom resource file format, you should derive from the ResourceSet class, override the GetDefaultReader and GetDefaultWriter methods, and pass that type to the ResourceManager(String, Assembly, Type) constructor. Using a custom ResourceSet can be useful for controlling resource caching policy or supporting your own resource file format, but is generally not necessary.

(my emphasis)

The documentation for ResourceSet explicitly says:

The ResourceSet class enumerates over an IResourceReader, loading every name and value, and storing them in a Hashtable

So we do know the exact caching strategy that you'll get by default.

[EDIT] Since you don't seem to believe me! :)

(1) Look at the documentation for the constructor ResourceManager(string baseName,Assembly assembly). It states:

This constructor uses the system-provided ResourceSet implementation.

(2) Now look at the documentation for ResourceSet. It states:

The ResourceSet class enumerates over an IResourceReader, loading every name and value, and storing them in a Hashtable.

Therefore this caching behaviour is indeed documented in MSDN, and additionally you can verify that this is what is happening by using Resharper to inspect the implementation.