Analyzing Performance (Documenting Progress, Results, etc.) about terasology

[BenjaminAmos]

Reducing the number of chunk threads appears to help with AbstractStorageManager::loadCompressedChunk.

LocalChunkProvider::processReadyChunk (per-chunk) behaves somewhat unpredictably in terms of performance. At times, a single call can take up to 150ms. At other times, the runtime is negligible.

[BenjaminAmos]

These methods appear to be consuming significant quantities of time (these are the highest execution times recorded). Results may be skewed by threading or other interruptions (such as GC collections).

Method	Max Duration (ms)
AbstractStorageManager::loadCompressedChunk	595
LocalChunkProvider::processReadyChunk (for all chunks)	379
rendering/CoreRendering:worldReflectionNode	291
rendering/CoreRendering:opaqueObjectsNode (MeshRenderer)	165
LocalChunkProvider::loadChunkStore	106
GameThread::processWaitingProcesses	42

[BenjaminAmos]

VoxelWorldSystem::onNewChunk is also quite expensive to run, it would appear.

[jdrueckert]

@BenjaminAmos Added the 10 longest per-call duration finds (with move than 1000 calls) of the trace to the issue description.

[jdrueckert]

During today's playtest, we identified a few areas to look into in more detail:

• ServerCharacterPredictionSystem - claiming to have "Received too much input"
• CharacterSystem - claiming that "Player xyz seems to have cheated: It stated that it performed an action from ... but the predicted position is ..."
• LocalChunkProvider and friends - stalling until flushing something, claiming "Chunk processing took too long this tick"
• ChunkEventErrorLogger - claiming "Multiple laods of chunk ..." in client logs