WinRTBridge.GCHandledObjects.FreeHandles

Could anyone from Unity explain scalability of WinRTBridge.GCHandledObjects.FreeHandles method in Unity 4.6?

We have a problem that performance of our game degrades over time (reloading level multiple times). I've spent quite some time profiling it and discovered that time spent in this method increases dramatically.
Early game - FreeHandles takes 10.98% of all CPU, after playing for some time grows to 37.07%. If is mostly influenced by COMInterlocked::CompareExchange which grows from 8.93% to 30.51%.

The worst thing that GC happens due to issues out of our control:
* physics, keeps allocating ContactInfo,
* Audio manager on WP8 seems to reallocate new buffer for each call of OnAudioFilterRead,
* UI is keen on allocating huge amounts of UIVertex [] of same size each frame (mostly in Text component).
Unity profiler shows none of those allocations, but Visual Studio profiler exposes it.
So in the end we can get 1-2 GC per second!

If I knew some of inner workings of FreeHandles algorithm I could check if I'm doing something wrong in our code. What is the working set of objects it operates on, how do they get there, when they are removed from working set?

Overall memory usage in our game is quite stable, so it is should not be caused by leaked C# objects, meshes or components.

Best Regards
Tomas

 

Yes master config, no debugger when running the game and frame drops appear after reloading levels couple of times down to a point when game is no longer playable.

We generate level geometry procedurally - no LoadLevel, single scene project. At load time there will be a lot managed/unmanaged transitions to upload all the meshes, generate components, etc. All these objects are destroyed.

Profiling is done using CPU sampling from Visual Studio Phone Performance Analyser:

Leaked things are:
ContactPoint allocated in UnityEngine.DLL (the ones from WinRTBridge are collected).

References are being held by GCHandledObjects.

The other two leaked things are Int32[] x2, Object[] x1 and finally WinRTBridge.GCHandledObjects+Block. Which are allocated when we call AnimationCurve.Evaluate.

I guess this explains the slow down behavior - some leaks from AnimationCurve.Evaluate and ContactPoints keep growing GCHandledObjects.Block and your collector had to process all of these refs.

I can get away without using animationcurves - it's for audio mixing only, but ContactPoints is needed for physics. I'm accessing contact points with foreach loop, in OnCollisionEnter/Stay. I do not store references to ContactPoints outside of foreach.

Any ideas?

 

Just to confirm - commenting out access to AnimationCurve.Evaluate and OnCollisionEnter/OnCollisionStay methods prevents leaks and performance degradation. Even empty OnCollisionEnter/OnCollisionStay methods are causing the leak and slowdown.

Problem is - these handlers are needed (would not be there otherwise). Should I submit a bug report?

 

"Quite stable" means that there is no big variation between level reloads. We generate the world procedurally and use custom pooling for CLR objects extensively - overall memory usage from our code varies between loads, but converges eventually.

I've submitted repro project, along with VS performance report.

 

No, not yet.

 

Just check in Unity5, no leaks with the repro project. We are migrating to Unity5 this week, I hope it will all be fine in Unity 5.

 

Thanks, looking forward.