summaryrefslogtreecommitdiffstats
path: root/src/main/java/net/minecraft/server/MinecraftServer.java
diff options
context:
space:
mode:
authorTravis Watkins <amaranth@ubuntu.com>2012-11-30 02:49:19 -0600
committerTravis Watkins <amaranth@ubuntu.com>2012-12-12 19:35:53 -0600
commit24143ef6a16bc8e079c8fdc950895a954a98273e (patch)
tree572130acfd3be0400df5041c1cea16f6e9468f3d /src/main/java/net/minecraft/server/MinecraftServer.java
parent11593b4592fd19c83fa939f39c5a22085e1a81ca (diff)
downloadcraftbukkit-24143ef6a16bc8e079c8fdc950895a954a98273e.tar
craftbukkit-24143ef6a16bc8e079c8fdc950895a954a98273e.tar.gz
craftbukkit-24143ef6a16bc8e079c8fdc950895a954a98273e.tar.lz
craftbukkit-24143ef6a16bc8e079c8fdc950895a954a98273e.tar.xz
craftbukkit-24143ef6a16bc8e079c8fdc950895a954a98273e.zip
Load chunks asynchronously for players.
When a player triggers a chunk load via walking around or teleporting there is no need to stop everything and get this chunk on the main thread. The client is used to having to wait some time for this chunk and the server doesn't immediately do anything with it except send it to the player. At the same time chunk loading is the last major source of file IO that still runs on the main thread. These two facts make it possible to offload chunks loaded for this reason to another thread. However, not all parts of chunk loading can happen off the main thread. For this we use the new AsynchronousExecutor system to split chunk loading in to three pieces. The first is loading data from disk, decompressing it, and parsing it in to an NBT structure. The second piece is creating entities and tile entities in the chunk and adding them to the world, this is still done on the main thread. The third piece is informing everyone who requested a chunk load that the load is finished. For this we register callbacks and then run them on the main thread once the previous two stages are finished. There are still cases where a chunk is needed immediately and these will still trigger chunk loading entirely on the main thread. The most obvious case is plugins using the API to request a chunk load. We also must load the chunk immediately when something in the world tries to access it. In these cases we ignore any possibly pending or in progress chunk loading that is happening asynchronously as we will have the chunk loaded by the time they are finished. The hope is that overall this system will result in less CPU time and pauses due to blocking file IO on the main thread thus giving more consistent performance. Testing so far has shown that this also speeds up chunk loading client side although some of this is likely to be because we are sending less chunks at once for the client to process. Thanks for @ammaraskar for help with the implementation of this feature.
Diffstat (limited to 'src/main/java/net/minecraft/server/MinecraftServer.java')
-rw-r--r--src/main/java/net/minecraft/server/MinecraftServer.java2
1 files changed, 2 insertions, 0 deletions
diff --git a/src/main/java/net/minecraft/server/MinecraftServer.java b/src/main/java/net/minecraft/server/MinecraftServer.java
index f0e6cf73..6b10bfcb 100644
--- a/src/main/java/net/minecraft/server/MinecraftServer.java
+++ b/src/main/java/net/minecraft/server/MinecraftServer.java
@@ -533,6 +533,8 @@ public abstract class MinecraftServer implements ICommandListener, Runnable, IMo
processQueue.remove().run();
}
+ org.bukkit.craftbukkit.chunkio.ChunkIOExecutor.tick();
+
// Send timeupdates to everyone, it will get the right time from the world the player is in.
if (this.ticks % 20 == 0) {
for (int i = 0; i < this.getServerConfigurationManager().players.size(); ++i) {