ResourceManager: Following Up
Yes, it turns out when you load up a ResourceManager it stays in memory. Given what it's doing, it's actually wicked fast.
I did some semi-scientific profiling. I wanted to compare it to rolling my own simple StringManager component.
Using four culture-region pairs (let's just call them CultureInfos) each containing 500 strings of 50 chars or less, pulling out 30 strings from them using a ResourceManager and satellite assemblies typically adds about 10-20ms of overhead [1]. Increase the number of string lookups appreciably and it scales pretty well (I'm not using high-res timers).
There is some initial latency associated with the initial pass as the satellite assemblies get loaded. Call it a couple hundred ms.
Okay, so my notion was that a straight two dimensioned lookup of strings would be more efficient. It is, about twice as fast. The same 30 strings pulled through my StringManager class took less that 10ms and was frequently unmeasurable. Increasing the number of accesses to 500 or 1000, still shows about a 2:1 performance margin.
The initial latency is quite a bit lower than with the ResourceManager; I'm parsing the string file with an XmlNodeReader and it's also a single file access as opposed to one file per CultureInfo for satellite assemblies.
The drawback to this approach is that you lose the fallback using a CultureInfo instance with a ResourceManager gives you. In its favor, storing string tables in a simple xml file requires a lot less in the way of build--no resgen, no al, no batch files. I didn't add a filewatch to my class yet, but if you did, you could basically deploy new strings without stopping a running instance of the application.
So I think it really comes down to asking how important fallback is. If you're building a website and pulling language accept headers to serve numerous languages dynamically, then it seems suitably important. If you're building a site and just want to be able to let users select which language they want to view your content in, it doesn't seem as critical.
The ms saved aren't massive, but it adds up in page generation and for the potential increase in performance and the loss of a lot of build/deployment headaches, it seems like a pretty valid way to handle language resources for ASP.NET sites.
[1] I'm using an ASP.NET hosted page as the test harnass and simply writing to Response.