Unity Physics - Slower Performance?

Hi all,

I feel like I must be missing something, and I apologize if I've missed literal comments here. I've been messing around with making a DOTS character controller (yay! being grounded works), and I'm just noticing my fps dropping way more than it should be.

I'm now comparing very basic scenes with standard vs dots physics, and dots physics is just way slower. I made a new test project (2019.4.6f1). I installed Entities (0.11.2), Burst (1.3.9), and Unity Physics (0.4.1), and DOTS Editor (0.8.2) for convenience. I have a scene with a standard plane and 6 capsules to drop on the plane. I added rigid bodies to the capsules. I disabled all mesh renderers so that isn't a confound. I'm getting 0.5 ms CPU with the classic GameObject + standard physics approach. Perfect. If I check convert to entity and let the conversion system do its thing I'm now looking at 3.8 ms on the CPU. Let me clarify, I'm not watching the conversion system working here, this is a consistent 0.5 vs 3.8 ms. That is a huge difference, and you can imagine how it gets amplified when you are doing more than just dropping a few capsules on a plane.

What is going on with this? Is this just where Unity Physics is right now as a preview package? Do I need to test this in build? I've had great luck with Jobs and Burst so far, and ECS too has been mostly great, but I'm not sure what to make of this.

 

This sounds too slow. Did you disable all the checks (jobs debugger, leak detection, Burst safety checks)? Also, a silly question, but did you make sure Burst was enabled? Furthermore, testing in build does help, but even editor shouldn't be this slow for sure.

 

@varnon Are you running a high core count cpu? You can try limiting the job system worker amount to see if it will have an impact. On my 3900x (12 cores/24 threads), physics (and other DOTS packages) just choke on the default 23 workers Unity assigns on my system by default. You can try to lower the worker amount (but it does it for the whole job system, not just for physics!) by using this: https://docs.unity3d.com/ScriptReference/Unity.Jobs.LowLevel.Unsafe.JobsUtility.JobWorkerCount.html

I've had cases where simply running 0-1 workers max has given me the best perf (while only using Unity's own DOTS packages) but never been in situation so far were I'd have gotten anything but degraded performance after max of 6 workers. This doesn't quite align with "performance by default" but DOTS is still early, I hope they figure some way to optimize the job system in the way.

 

Thanks for the responses. The award for most right answer goes to petarmHavok, but not quite for the reasons I was expecting.

It turns out leak detection was on (with full stack traces ). I didn't check for that in this test since I made a brand new project with a minimal install. Apparently, some of the options in the Jobs menu persist across projects and versions of Unity. I've been testing lots of DOTS things as I'm learning, and I remember turning it on for one test, and then that persisted everywhere. The performance drop it causes then was only really evident once I started doing physics tests. That puts me at 0.5 ms vs 1.0 ms. I'm seeing similar slower, but understandably slower, performance in my actual project now too.

From there, rz_Olento is also correct. I do indeed get better performance with less threads (max of 15 job worker threads on this computer). It seems to be a linear decrease, but I would really need to stress it to test for sure. I can get it to 0.7ms at best. I'm assuming that the thread overhead will be inconsequential in a real project that is actually doing complex things. I agree that it would be nice to have a little more control over the number of threads used per system or system group.

 

I think you should try with 1000 characters and see what that does.

I know from my own tests that 1000 characters (whether they are dynamic rigidbodies or raycast-based) is about 5-10x faster in DOTS than it is in Monobehaviour. So if you try this and see that DOTS performance is still not significantly faster, that would be a pretty strong indicator that there's something missing/wrong in your setup

But yeah, if you do get the expected performance boost in DOTS with this 1k characters test, then we can assume that the culprit in the performance difference you were seeing with 6 characters is just the scheduling cost. With an amount of physics bodies that is this low, I think maybe setting the "thread count hint" to 1 in the PhysicsStep component might help you (but I haven't tested)

 

One further option to try setting the Thread Count Hint in the

PhysicsStep

component to zero for small simulations. This is primarily use by Havok Physics at the minute, but if you set it to zero then the simulation becomes single threaded and you don't get the overhead of scheduling a lot of jobs. We definitely would like to use this Thread Count Hint more on the Unity Physics side just @rz_0lento mentions to limit thread use specifically on the scheduled Physics jobs.
If you want even more control and only want a single job for stepping the simulation, you can use the

StepImmediate

interface, but that involves a bit more of you only logic to override the

StepPhysicsWorld

system. The ImmediateMode sample uses this interface to project a simulation forward into the future.

 

I was looking at this recently and there are enough jobs that are just hardcoded to 32 work stealing to make the thread hit count not have much of an impact if you have lots of cores. Less impact the more you have.