Significantly optimize updating RenderChunk positions in ViewFrustum #782
Conversation
Rather than simply performing the updates asynchronously in a different thread (which introduces potential race condition and just offloads the issue to another core), this actually makes the RenderChunk position updates significantly faster in most common cases. We observe that under normal gameplay circumstances, the camera rarely moves more than one cube per frame. By detecting this common case, we can efficiently skip RenderChunks whose position hasn't changed, as when the camera moves by one cube in a given direction, only one 2D slice/plane of RenderChunks are actually changed. On my machine, with a horizontal render distance of 48 chunks and a vertical render distance of 16 cubes, and while flying around at maximum speed in spectator mode, this change reduces ViewFrustum#updateChunkPositions() from ~22% of the total client thread CPU time to ~2.4%, nearly an order of magnitude performance improvement.
|
Can you measure exact time in microseconds, with various render distance values, including max possible horizontal+vertical? |
|
Do you want the exact time for one update in a known direction, over a fixed sample duration with a known movement pattern, or average time for many updates with a random movement pattern? This is hard to microbenchmark since the exact update durations are going to depend on the direction which a player is moving in, as well as where the player is relative to the origin point (not to mention that the actual time is going to be affected by the number of RenderChunks which are actually built when their position is changed, or worse - if the RenderChunk is being built we may have to sleep while acquiring |
|
Average/minimum/maximum time per invocation when moving normally, this basically tells me how much stutter it's actually going to cause |
|
I couldn't go higher than 20 vertical with 64 horizontal render distance, the client takes so long to allocate all the buffers that it gets timed out. All durations in milliseconds.
This PR seems is clearly significantly faster than the original code at high render distances, and outperforms the original code on average at low render distances. At low render distances this PR tends to have longer spikes than the original code (about 2x longer), despite having a lower average duration. My guess is that this is caused by the VM occasionally having to deoptimize and recompile the code when one of the conditions is reached for the first time. |
|
I would like to figure out further improvements, but 3ms in the max render distance case looks mostly good enough |
2 participants
Rather than simply performing the updates asynchronously in a different thread (which introduces potential race condition and just offloads the issue to another core), this actually makes the RenderChunk position updates significantly faster in most common cases.
We observe that under normal gameplay circumstances, the camera rarely moves more than one cube per frame. By detecting this common case, we can efficiently skip RenderChunks whose position hasn't changed, as when the camera moves by one cube in a given direction, only one 2D slice/plane of RenderChunks are actually changed.
On my machine, with a horizontal render distance of 48 chunks and a vertical render distance of 16 cubes, and while flying around at maximum speed in spectator mode, this change reduces ViewFrustum#updateChunkPositions() from ~22% of the total client thread CPU time to ~2.4%, nearly an order of magnitude performance improvement.