I am casually reading about the Memory<T> class in C#, to figure out if I can use it to "format" memory allocations to be more contiguous. I don't know a lot of the finer details of computer memory, but I was thinking that if I can ensure that all of the UI classes in my game are allocated in a contiguous block of memory, the whole thing can be updated without cache misses, right?

Anyways, my question is, if I for instance have a UIManager class that instantiates, and keeps references to, ALL other UI classes in the game, can I simply use an instance of Memory<UIManager> to allocate all of the UI contiguously? Or would I need a bunch of different Memory<T> instances? And in the latter case, do I have any control over whether it will be allocated contiguously or not? I've tried googling and reading documentation, but I can't figure it out.

I am using the Monogame framework for my game btw.

I am casually reading about the Memory<T> class in C#, to figure out if I can use it to "format" memory allocations to be more contiguous. I don't know a lot of the finer details of computer memory, but I was thinking that if I can ensure that all of the UI classes in my game are allocated in a contiguous block of memory, the whole thing can be updated without cache misses, right?

Anyways, my question is, if I for instance have a UIManager class that instantiates, and keeps references to, ALL other UI classes in the game, can I simply use an instance of Memory<UIManager> to allocate all of the UI contiguously? Or would I need a bunch of different Memory<T> instances? And in the latter case, do I have any control over whether it will be allocated contiguously or not? I've tried googling and reading documentation, but I can't figure it out.

I am using the Monogame framework for my game btw.

• c#
• memory
• memory-management
• monogame
• allocation

2 Answers 2

If you have "UI classes" (important word here: class), then Memory<T> is irrelevant and will not make anything contagious: the objects will be wherever on the GC heap they were allocated. Having the references to those object contiguous really makes very little difference, and is not very different to what you already have available via List<T> or T[].

Specifically: Memory<T> is really just an accessor for Span<T>, and Span<T> is just a slice over some existing memory - usually, but not always: an array. If the T in that is a class: it is only the references (not the objects) that are next to eachother.

This smells a lot of premature optimization. There are certainly cases in game programming that need a lot of optimization and where cache usage is critical. But the vast majority of game code is not performance critical. The performance critical parts are usually things dealing with graphics, animations etc. My guess is that UI related code is not particularly performance sensitive.

But the great thing is that you do not have to guess! There are lots of profiling tools that can tell you how much time various parts of your program takes to execute. There are also lower level tools that provide much more detailed information, but require more knowledge on how to use correctly. It is very important to measure performance before any optimization, otherwise you risk spending lots of time "improving" something, and in the end you have no idea if it made any difference, except that the code is much more difficult to read.

You really do not have control over how classes are allocated, that is managed by the runtime. The usual approach is to just be careful with object lifetimes to avoid unnecessary GCs. You can have better control over how structs are allocated, but they can also be more difficult to use correctly and efficiently.

Keeping memory contigous is most important when the memory access patterns are easily predictable, like iterating over an array, since this can allow the CPU to pre-load memory it will need in the future. This is much less effective in "branchy"-code, and most game logic related code tend to be fairly branchy.