koobas.hobune.stream
Is there a way to accurately measure heap allocations in unit tests?
Allocating temporary objects on the heap every frame in Unity is costly, and we all do our best to avoid this by caching heap objects and avoiding garbage generating functions. It's not always obvious when something will generate garbage though. For example:
enum MyEnum {
Zero,
One,
Two
}
List MyList = new List();
MyList.Contains(MyEnum.Zero); // Generates garbage
MyList.Contains() generates garbage because the default equality comparer for List will use objects which causes boxing of the enum value types.
In order to prevent inadvertent heap allocations like these, I would like to be able to detect them in my unit tests.
I think there are 2 requirements for this:
A function to return the amount of heap allocated memory
A way to prevent garbage collection occurring during the test
I haven't found a clean way to ensure #2. The closest thing I've found for #1 is GC.GetTotalMemory()[UnityTest] IEnumerator MyTest() { long before = GC.GetTotalMemory(false); const int numObjects = 1; for (int i = 0 ; i < numObjects; ++i) { System.Version v = new System.Version(); } long after = GC.GetTotalMemory(false); Assert.That(before == after); }
The problem is that GC.GetTotalMemory() returns the same value before and after in this test. I suspect that Unity/Mono only allocates memory from the system heap in chunks, say 4kb, so you need to allocate <= 4kb before Unity/Mono will actually request more memory from the system heap, at which point GC.GetTotalMemory() will return a different value. I confirmed that if I change numObjects to 1000, GC.GetTotalMemory() returns different values for before and after.
So in summary, 1. how can i accurately get amount of heap allocated memory, accurate to the byte and 2. can the garbage collector run during the body of my test, and if so, is there any non-hacky way of disabling GC for the duration of my test?
TL;DR
Thanks for your help!
No, there is no reliable method inside the runtime. GetTotalMemoty returns:
A number that is the best available approximation of the number of bytes currently allocated in managed memory.
The actual numbers are only available to the runtime itself. However when you use the Unity profiler to figure out what is going on regarding memory allocations. The profiler hooks into most methods. Keep in mind that the profiler has a "deep mode" which shows almost a line by line report for each method called (actually more a method by method report). Note that the managed memory allocated by a method is summarized into one "GC.Alloc". If you want to further narrow down the memory of a particular section you can use:
UnityEngine.Profiling.Profiler.BeginSample("SomeUniqueName");
// The code you want to profile
UnityEngine.Profiling.Profiler.EndSample();
To get a seperate sample entry in the profiler. You can easily search for that name in the profiler so you don't need to find the frame manually and don't need to trace the callstack manually. Once you have selected your sample you can remove the search string and your sample should be selected in the normal view.
Preventing garbage collection was introduced in NET 4.6 so depending on your Unity version, script backend and .NET version selection it may not be available to you.
So in short: No, there is no way to manually determine how much memory was allocated within a certain code section through code. And no you can't really suppress garbage collection apart from the fact that it wouldn't help. So you can't incoperate memory allocation into unit tests.
Just as a side note: The System.Version class contains just 4 int values. This is 16 bytes in total. However each class instance has some additional overhead like the type pointer, vtable and maybe some memory alignment. At least in my tests one Version instance requires 32bytes of memory.
About your first example: Yes, Mono has some bad habits / implementations here. In normal .NET the default comparer actually creates a proper generic comparer (based on IEquatable<T>) to get a garbage free comparison. Mono has several of these poor implementations (same goes for foreach and IDisposable for struct enumerators). Though this is implementation dependent behaviour that you can't catch with unit tests in the editor properly.
