Recently I switch to use laptop and found that I only get roughly 8-12 fps which extremely slow with the same of my dots netcode project. It’s powerful Nvidia GTX 1070 gaming laptop with Intel 6700HQ CPU and Samsung SSD 850 PRO 512 GB. One interesting thing I found is editor failed to utilize the CPU that only consume until roughly 39% which is too low utilization. I think dots netcode needs to further improve it to make it utilize more CPU and further improve fps. Currently is there any performance improvement I can expect for dots 0.50 release?
The picture is not loading for me, I assume that was a profiler screenshot?
There are optimizations in 0.50, but without seeming what is actually slow I can’t tell if it is something we have improved or not so I don’t know if it will improve your case.
It’s just CPU utilization at windows task manager. It clearly show that Unity editor still can use a lot more CPU but it didn’t do that which is really weird.
Btw I using forum file upload to upload image. Not sure why u can’t view it. Anyway I reupload again to 3rd party image hosting site and link it at here.
@CMarastoni@timjohansson Any new update? After I upgrade my big project to 0.50, the CPU utilization at editor still extremely low that still not even reach 50% utilization and just 10+ fps on runtime at my another old i7-3610QM laptop. I think maybe there is performance improvement at 0.50 but tiny improvement. If I remember correctly before I upgraded to 0.50 I only get single digit fps at editor on runtime. Any plan to fix this editor performance issue that make it utilizes more CPU power specially at laptop?
Without seeing a profiler capture or screenshot of the timeline view I have no idea what is actually slow in your case. I don’t even know if it is a netcode issue or some other system which runs more frequently because of the fixed update logic in netcode.
Have you tried disabling jobs debugger and leak detection in the jobs menu and if so how big impact did that have?
For 0.50 I would recommend trying out the new server tick batching feature to reduce CPU load in the editor. If you create a singleton entity with a ClientServerTickRate component where you set MaxSimulationLongStepTimeMultiplier = 4 and MaxSimulationStepsPerFrame = 1 the behavior will change so instead of the server ticking up to 4 times per frame when it can’t keep up it will only ever tick once - but it will use a longer delta time if it is running too slow. The results will be a bit less accurate, but performance should be significantly better. See Struct ClientServerTickRate | Netcode for Entities | 0.50.1-preview.19
@timjohansson Sorry for late update. Here’s the profiler screenshot. The bottleneck mainly coming from Entities and dots physics packages. Now it becomes less and less fps even at desktop pc and can’t achieve. From what observe, the fps will keep dropping when u add more and more ghosts but currently I just add only a number of counts of ghost ady drop fps until lower than 30.
Seems like after dots netcode package is installed. This slow RecordingSystem will be enabled by default and no way to disable it. Can u provide me unofficial fix for this issue? Actually which part of dots netcode code causing this issue?
The slowest part is dots physics. From my test, you just add only a few of ghost with physics collider the u can see the fps will drop massively even at desktop pc. For my desktop pc drops from solid 60 fps to just around 30 fps. Is that currently the known issue and only able to fix at dots netcode 1.0 release?
@timjohansson@CMarastoni After I further dig the issue, I found when I removed all the physics related components from client, the performance improved massively. Is that because the current dots netcode 0.50.1-preview.19 still not really support physics really well yet?
Another issue is RecordingSystem will be enabled by default and no way to disable it after installed dots netcode package. From what I discovered, the only way I found is to just comment out the system that update loop to update RecordingSystem. I think dots netcode 0.51 release needs to solve this issue. This will still improve some performance at editor.
RecordingSystem only runs when the profiler is running, if you close your profiler it no longer runs. (Also it’s an entities not netcode feature)
protected override void OnUpdate()
{
if (!Profiler.enabled)
return;
As for physics, if you want to make it run faster in editor turn off integrity checks (DOTS → Physics → Enable Integrity Checks) as well as jobs debugger. Both of these slow it down quite a bit. Apart from that, FixedUpdate causes a spiral of performance issues if your FPS drops low because it needs to run multiple times per frame, which lowers fps so it needs to run even more etc.
I already test it multiple time. As long as u have dots netcode package installed. RecordingSystem will just run itself even you close profiler windows. There’s no way to disable it. I believe there is something inside dots netcode package. Maybe is bootstrap issue I dunno.
Just let u know that it just drops half fps at desktop pc when I client ghost has physics related components at editor and at the same I enabled physics prediction. If not mistaken real build will also lag but not super lag like editor. Maybe @timjohansson can provide some insight.
I added a Debug.Log to update in the record system in our netcode sample project. In that project it only runs when the profiler window is open so I can’t reproduce that issue.
How are you checking if it is running and how are you checking that it is caused by netcode? Do you have a small project where you can add and remove netcode to test both?
When you enable prediction the physics systems will run multiple times per frame on the client, which makes the settings @tertle mentioned have an even bigger impact.
Apart from running multiple times there is no big difference from how physics normally works, so any performance tweak you would normally do to physics will help even more. Another thing which could help depending on number of physics objects etc is to run single threaded physics (see PhysicsStep.MultiThreaded).
