Help Extreme frame drops while using the debugger

[Voolg]

Hello,

I noticed in my project some extreme frame drops, that seems to be linked to Obi, although even using the profiler it was extremely difficult for me to figure out why or where exactly. Those drops only happened if I had the Visual Studio debugger enabled. Always, and only, rendering it almost unusable.

Typically, I would run the game in Unity (with debugger) just fine until, seemingly randomly, each frame would suddenly start to take ~2000ms, for around 30s. Then the game would run smoothly again for 10s to 30s, before getting insane drops again, and so on. Those drops are *not* linked to any change of the code being executed.

The intensity of the issue instead seemed to scale with of much ObiSolver.SpatialQuery() I would overall use, as if each of them would lead to a delayed spike of garbage collection of some sort.

I finally I narrowed down the source of my misery to ObiNativeList.Dispose(), specifically those two lines:

Code:

#if ENABLE_UNITY_COLLECTIONS_CHECKS
            // dispose of atomic safety handle:
            AtomicSafetyHandle.CheckDeallocateAndThrow(m_SafetyHandle);
            AtomicSafetyHandle.Release(m_SafetyHandle);
#endif

Commenting those lines got me rid of the insane frame drops that I was getting every time I used the Debugger.

So the point of this post is to bring this to your attention, and then to ask you what are those lines about and if I can safely comment them without creating other issues.

[josemendez]

Hi,

Never heard of a similar issue, to be honest. These two lines are part of Unity's job safety system. Basically, they check whether the managed memory associated to the list can be safely deallocated (that is, no double deallocations or deallocations of uninitialized data) and just throw an exception if it can't. It's only used in the editor (stripped away in builds) if you have the "Enable Safety Checks" option enabled in the Jobs menu.

Commenting them off should have no negative effects at all.

Typically, I would run the game in Unity (with debugger) just fine until, seemingly randomly, each frame would suddenly start to take ~2000ms, for around 30s. Then the game would run smoothly again for 10s to 30s, before getting insane drops again, and so on. Those drops are *not* linked to any change of the code being executed

What are those 2000 ms being used for? Did you check the profiler?

kind regards,

[Voolg]

Hey, thanks for the quick reply.

I checked the profiler yes, but I struggle to make a lot of sense out of it, apart that it seemed related to Obi operations. Here are two profiler screenshots with highlights of what seems relevant to me. One is editor profiling, one is play mode.

Again I repeat myself, but keep in mind that the code being executed is the same before and during the ~2000ms spike AND this only happens if the VS debugger is active.

Also something else that might be related: when I tried to replicate the issue on a new, simple project, I got exceptions on the two lines I mentioned earlier. See the attached screenshot.
This is a new, very simple standard pipeline project (although my main project uses URP) that only make SpatialQuery calls (I couldn't reproduce the lag spike there). On my main URP project, there is no caught exception here.

Also I just tried disabling the safety checks from the Jobs menu, as you indicated, but somehow the spikes still occur unless I comment the two lines.

Ultimately, commenting those two lines works well enough for me, but if you want to investigate this issue more I'll do my best to assist. I just hope it's not an issue that I somehow created myself, as I don't mean to waste you time on this.

[slimedev]

I also had SpatialQuery slowing down a FixedUpdate()
Try making a copy of it that returns the NativeList, to later Dispose() yourself