Room for performance improvement in MyCubeGrid.Dispatch

Viktor Ferenczi shared this bug 5 months ago
Reported – Awaiting fix

Game version: 1.200.030

Method: MyCubeGrid.Dispatch

Main thread CPU load on large multiplayer servers: ~5.9%

This is measured without the invoked queue entries, so this is just the plain administrative overhead. This is slow, at least on multiplayer servers with 2000+ grids. I was running the world save on my machine with no players logged in, so this is just the "standby" load.

Low hanging fruit would be the code change attached to this ticket, please diff it with the original (both files included).

I would also consider just pre-creating all four List<MyCubeGrid.Update> objects in m_updateQueues with some initial capacity (depending on type, needs profiling) for all grids. Extend the array to 5 items and leave the zero index (MyCubeGrid.UpdateQueue.Invalid) null, so you can index it directly with the enum value.

This way GetQueue could be removed completely, replaced with a fixed array lookup and a subsequent null check. Also manually inline BeginUpdate into Dispatch, because the compiler does not do it. The EndUpdate is not that much of a problem, based on profiling.

Please also consider how these lists of structs are used, maybe there is a faster way to do this kind of administration in a less memory intensive way. I could not test my code change and cannot play with possible solutions, because your MyCubeGrid.Update struct is internal... Please don't do that to us. Leave as much as possible public, so plugin devs can hack around them easily without having to use a publicizer or slow reflections. Thanks!

Replies (2)

photo
1

At the end of the fixed method it should be updateList.RemoveRange, not RemoveAt.

photo
1

Hello, Viktor,

thanks for letting us know. Issue was reported internally.

Kind Regards

Keen Software House: QA Department

Leave a Comment
 
Attach a file