I’ve noticed that when running NuiTrack with the C# wrapper, the GC is running almost continuosly; see VS memory diagnostic window below.
This happens even with all the most basic examples.
Tracking the memory objects being created and disposed, I noticed that new DepthFrame, ColorFrame, UserFrame objects are created, including their internal Byte[] Data arrays. but they’re not reused in the next frames.
This may be convenient for naive, simple or short lived applications but for applications that need to run for HOURS, this is a very inefficient way of handling memory, since the GC is running all the time.
consequences of not reusing the byte buffers on new frames:
-
It forces the GC to run all the time, increasing the possibility of triggering a generation 2 GC, which blocks the application for a few seconds; very bad for real time applications. Even if the GC only runs a generation 1 recollection, running the GC all the time consumes CPU.
-
Huge buffers, like those used for allocating images, are allocated in the Large Object Heap, not in the normal heap, this is potentially dangerous because LOH objects are not automatically defragmented by the GC, which can result in an unexpected Out Of Memory exception when trying to allocate a new buffer, even if the system reports there’s enough memory.
-
It increases the memory requirements pressure. All previously allocated buffers stay in memory until a new GC runs. The only way to reduce memory pressure is to manually run GC after reading every frame. This would be incredibly inefficient.
As an example, here’s a screenshot of visual Studio Memory diagnostic, running NuiTrack vs running KinectSDK:
KinectSDK:
NuiTrack:
as you can see, NuiTrack consumes a lot more memory (due to not releasing/reusing previously allocated frames), and triggers GC recollections a lot more often.