Question How to inspect EndFixedStepSimulation EntityCommandBuffers?

How can I inspect the list of commands queued in the various

EntityCommandBuffers

of

EndFixedStepSimulationEntityCommandBufferSystem

?

The

EndFixedStepSimulationEntityCommandBufferSystem

of my project seems to be doing a lot of work (10.47ms of the 11.90ms of the

SimulationSystemGroup

in a standalone development build) and I'd like to inspect its command buffers to see if I've accidentally created unnecessary work for it to do.

EDIT: Even inspecting the lengths of the command buffers would be helpful. I asked a more general version of this question in a thread on the main DOTS forum.

 

Looks like you got some help on the other thread (I agree with those advices). Did you manage to get to the bottom of it?

 

I didn't get to the bottom of it, but tertle was right that my use of the ECB was hiding things. I went through a cycle of unhiding things, which included disabling some custom systems and the DebugStream system and I arrived at this screenshot for this physics stress test (three piles of 900 entities colliding with each other, for a total of 2700 entities; the screenshot in the other thread had only two piles and some extra systems enabled).

I don't know why the contacts and jacobians are being built twice per frame, or why MemoryManager.FallbackAllocation is showing up or if that's normal.

It's off topic, but where I am now is going over the DOD basics. My inability to reason about my context is motivating me to simplify things, by getting to the bottom of them. I've downloaded the Intel 64 manual.

EDIT:

Here are more screenshots for more context. There seems to be an alternating cycle of building the jacobians twice per frame for a few frames, then once per frame for a few frames, and so on:

Once per frame:



Here's the zoomed out wave behavior:



EDIT 2 (after tertle's reply):

More context:

The above is from a standalone develop build. The entities are convex colliders.

 

This is what happens when your framerate is low and you have a fixed update group running. It has a fixed update rate of 50 (60?) times a second, so if you're fps is below 50 then it has to update multiple times per frame at some point to reach its target update rate.

If you're fps is 25, it will update 2 times every frame. if you're fps is between 25-50 it will update 1-2 times/frame.

This does cause a bit of a feedback loop, where because now it has to update multiple times per frame so your fps is lower therefore it has to update more. This tends to be more noticeable in editor than builds because you often have a lot of overhead so your fps is lower than it would be in a build (just script debugging hurts your fps pretty badly.) Ideally you'd always be trying to target 60+ fps in a build therefore this behavior wouldn't usually occur.

 

Yes, constantly high physics step durations will cause even bigger slowdown, since fixed timestep is used. This thread is very useful.

You could enlarge the fixed timestep duration (lower FPS) if you know your scene is heavy, using UnityPhysicsSamples\Assets\Demos\2. Setup\2b. Motion Properties\Scripts\MotionSmoothingSetup.cs .