-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Minor
-
None
-
Affects Version/s: None
-
Environment:
Ubuntu with a modern AMD processor.
-
CraftBukkit version 3544-Spigot-475f600-991aeda (MC: 1.19) (Implementing API version 1.19-R0.1-SNAPSHOT)
-
Yes
Versions
1.19
Problematic behavior
Loading chunks in modern minecraft versions became painfully expensive with currently lagspikes up to 800-1600ms on the main thread.
This is mostly triggered by single actions causing an unloaded chunk to load. Like teleporting the player or reading block states.
So when a player using Essentials teleports to their home, or already listing the homes, which reads the bed block state, causes such a lagspike.
Expected behavior
The chunk loading should take a moderate time like 10-20ms or an API should be added which allows to load a chunk asynchronously, where a callback can be used which is then executed synchronously, when the chunk is loaded.
How to recreate
Use player.teleport() to an unloaded chunk.
Use location.getBlock() of an unloaded chunk.
The results will be visible with timings, spark, and other profilers.
Notes
Paper seems to have done both already. Synchronous chunk loads take a moderate time and there exists a world.getChunkAtAsync() method which returns a CompletableFuture<Chunk>.
The PaperLib brings an inspiration how such an API could looks like.
https://github.com/PaperMC/PaperLib
Also in the screenshot we can see that minecraft already has a logic for this with the IAsyncTaskHandler. But spigot seems to wait and block on the asynchronous tasks.
[SPIGOT-7094] massive lagspike when loading chunks
Modern Minecraft versions require a fast SSD to run decently. An old hard drive or network storage can lead to this lags for chunk loads on the main thread.
Black Hole
added a comment - - edited Modern Minecraft versions require a fast SSD to run decently. An old hard drive or network storage can lead to this lags for chunk loads on the main thread. 
It's already tested with NVMe SSD hardware. The timings screenshot indicates that the "real" load is only ~6.19ms.
And the rest of the time is spent waiting on the IAsyncTaskHandler which seems to be parked.
In comparison, Paper already fixed this, which reduces the overhead to 6-15ms.
This is clearly a software problem, not a hardware problem.