OvrAvatar Massive GC Allocation

Thank you for looking into this Imperativity! I'm not sure if this helps, but here's a screenshot of the profiler. Check out that GC action. It takes 2-3 times more processing time than everything else in the scene combined =)

om

imperativity said:

Hi,

It looks like this issue is here to stay for a little before an update is issued to address this. Apparently this is what has remained after other, more serious GC issues were removed prior to release. The remaining issues are caused by the Microsoft interop layer between native code and C#, which generates garbage as a side of effect of sending objects across the boundary.

There is a way to fix this by making some changes to the native API so that objects won't need to be sent across each frame and there will be a release in the future addressing this.

Thank you for the update! I appreciate it.

The issue seems to be every frame calling OvrAvatar.UpdateSDKAvatarUnityState()

It builds a new HashSet of all 'deletableNames' components in the overAvatarComponent to see if they are tracked components, this seems excessive every frame.  The comments in this code also seem to indicate this is only expected to be called per run?

//deletableNames contains the name of all components which are tracked and were
//not present in this run

It then uses RemoveAvatarComponent(string name) to Destroy any objects in deletableNames.

What's really weird is the fact that every frame it calls OvrAvatar.getRenderPart() which allocates marshalled memory (not a buffer for each call or stored IntPtrs from the last call) on the same 14 (in my case) elements.

This seems wrong as I thought IntPtr is a pointer, a way for C# code to access data used by a DLL so once it's acquired why keep updating it every frame, never mind reallocating more space every frame?

Hello!

Any update on this? I am also getting GC allocations:
https://imgur.com/aRHE5sj

OvrAvatar ( 1.26.0) allocating GC every frame in Unity ( 5.6.3f1 )