Profiling - Physics.Processing self time is over 1 millisecond!

Currently, we're trying to optimize our game. We noticed in the profiler that 1.26 milliseconds is being taken up by the sample named "Physics.Processing". This cost is listed under "Self MS", and distinct from "Total MS", it doesn't include any of its children samples' time. For example, this doesn't include the cost listed under the "PhysX.PxsSap.sapUpdateWork" sample nor any of its sibling samples.

I'm using Unity 5.6, but this cost may still happen in newer versions of Unity. This is also measured from a build, not in the editor.

What is happening in the Self MS of Physics.Processing? I really need to get cut down this 1.26 MS.

The curious thing about our project is, while we have a lot of colliders, virtually all colliders are supposed to be stationary. In fact there are only a handful of non-static, kinematic rigidbody box colliders which we intend to allow to move around. You'd think that PhysX wouldn't really need to process much if virtually all of the colliders in the scene are perfectly still.

Knowing what happens in this sample could help me narrow down what is causing PhysX to barf.

It might be worth noting that Physics.Simulate takes almost no time to compute.

Listed here are the noteworthy Self MS costs associated with physics that we're currently struggling with:

- 1.26 - Physics.Processing
- 0.87 - Physics.FetchResults
- 0.48 - PhysX.PxsSap.sapUpdateWork
- 0.25 - PhysX.PxsSap.sapPostUpdateWork
- 0.13 - PhysX.PsxAABBManager.aggregateOverlap
- 0.11 - Physics.Raycast
- 0.11 - Mesh.Bake Scaled Mesh PhysX CollisionData
- 0.10 - PhysX.ScScene.broadPhase

- 3.31 - Total

 

So, we've determined that one of the conditions necessary to produce the slowdown was this:

A single character controller being activated and deactivated every frame. Without this, the cost from physics per frame dropped to 0.3 ms.

It might not be the only necessary condition (i.e. it may not be sufficient to produce the slowdown) as we have several thousand colliders in the scene. But nonetheless it is extremely odd that a single character controller activating and deactivating could cause so much damage.

I'm not sure what to do as this per-frame deactivation and reactivation was necessary to fix a bug with the character controller.

 

When you enable and disable colliders, the collider is not hidden but destroyed and created. The character controller is not using colliders though, it's a bunch of casts.

Don't have enough information to help. There's been a few bug fixes over time.

Also I'd prefer a screenshot of profiler data, you don't list the number of calls and other relevant data either so I'm just guessing.

Is this relevant?
https://issuetracker.unity3d.com/is...dot-processframe-causing-degraded-performance