3

I have a static class with a static List inside of it.

public static class Translations {
    public static List<string> Resources {get; set;}
}

Does it make sense to MemoryCache that List? Or by being static is already kept in memory, the same list for all users and there's no need to memcache it?

Cătălin Rădoi
  • 1,804
  • 23
  • 43
  • "kept in memory" depends on a lot of things; the list shown will last as long as the app-domain lasts, which *usually* means as long as the process; however, some environments actively recycle processes, which would lose the list; what is the actual scenario here? also: are you ever adding/removing/etc to that list? because if you are: there's a possible thread-race condition here – Marc Gravell Sep 15 '21 at 13:27
  • MVC / Yes, I am updating the list as well. So I should memcache it then? – Cătălin Rădoi Sep 15 '21 at 13:31
  • these two things are unrelated; whether you use an out-of-process cache depends on a: your process lifetime, and b: the cost of building the data - you haven't told us either of those things; and if you're updating the list: *you need to deal with the race problems* - an out-of-process cache doesn't help with that *at all* - it is a completely separate issue; it is sort of like asking "my car keeps getting flat tyres; what color should I paint it?" – Marc Gravell Sep 15 '21 at 13:47
  • I am using the MemoryCache.Default. No fancy things here. And I am keeping an entire DataTable in memory (Some translations that are missing from RESX) – Cătălin Rădoi Sep 15 '21 at 14:55
  • I think it would really help if you could provide more detail for things like what is the list of 'Resources'? How frequently does it get updated? How expensive an operation is it to create that list? – sr28 Sep 15 '21 at 14:55
  • 1
    ah, I see; you used the phrase "memcache", and I assumed you meant the out-of-process storage engine - my bad, but most of what I said remains – Marc Gravell Sep 15 '21 at 15:35

1 Answers1

3

If we're talking about in-process memory, then a static field will have exactly the same lifetime as anything in MemoryCache.Default, but the field will be more direct, and therefore faster. The bigger problem, however, is the race condition if you ever mutate the contents of the list after it has been assigned, since multiple threads could be looking at the data at the same time (bad things). It is probably a good idea to use some kind of immutable collection (ImmutableList<T>, for example), to avoid any complications there.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Thanks for the ImmutableList Why should I ever use MemoryCache.Default then, when I can simply use static always? – Cătălin Rădoi Sep 15 '21 at 16:06
  • @CătălinRădoi MemoryCache operates more like a string-keyed dictionary for when you need multiple values that might not be known at build time, for example: per user, per region, etc - by composing a key. It also incorporates thread safety concerns, garbage collection / capacity concerns, and a few other things that don't really apply in your case – Marc Gravell Sep 15 '21 at 19:58
  • @CătălinRădoi [Why use System.Runtime.Caching or System.Web.Caching Vs static variables?](https://stackoverflow.com/questions/5986466/why-use-system-runtime-caching-or-system-web-caching-vs-static-variables) – Theodor Zoulias Sep 15 '21 at 22:18