Paper/src/main/java/net/minecraft/server/PlayerChunkMap.java

303 Zeilen
9.7 KiB
Java

package net.minecraft.server;
import java.util.ArrayList;
import java.util.List;
2012-11-06 13:05:28 +01:00
// CraftBukkit start
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.
2012-11-30 09:49:19 +01:00
import java.util.Collections;
2012-11-06 13:05:28 +01:00
import java.util.Queue;
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.
2012-11-30 09:49:19 +01:00
import java.util.LinkedList;
2012-11-06 13:05:28 +01:00
// CraftBukkit end
2012-12-20 05:03:52 +01:00
public class PlayerChunkMap {
2012-07-29 09:33:13 +02:00
private final WorldServer world;
private final List managedPlayers = new ArrayList();
private final LongHashMap c = new LongHashMap();
private final Queue d = new java.util.concurrent.ConcurrentLinkedQueue(); // CraftBukkit ArrayList -> ConcurrentLinkedQueue
2012-07-29 09:33:13 +02:00
private final int e;
private final int[][] f = new int[][] { { 1, 0}, { 0, 1}, { -1, 0}, { 0, -1}};
private boolean wasNotEmpty; // CraftBukkit
2011-05-26 14:48:22 +02:00
2012-12-20 05:03:52 +01:00
public PlayerChunkMap(WorldServer worldserver, int i) {
2012-07-29 09:33:13 +02:00
if (i > 15) {
throw new IllegalArgumentException("Too big view radius!");
2012-07-29 09:33:13 +02:00
} else if (i < 3) {
throw new IllegalArgumentException("Too small view radius!");
} else {
this.e = i;
2012-07-29 09:33:13 +02:00
this.world = worldserver;
}
2011-05-26 14:48:22 +02:00
}
2011-02-23 13:56:36 +01:00
2011-05-26 14:48:22 +02:00
public WorldServer a() {
2012-07-29 09:33:13 +02:00
return this.world;
}
public void flush() {
2013-03-25 05:22:32 +01:00
// CraftBukkit start - Use iterator
java.util.Iterator iterator = this.d.iterator();
2012-07-29 09:33:13 +02:00
while (iterator.hasNext()) {
2012-12-20 05:03:52 +01:00
PlayerChunk playerinstance = (PlayerChunk) iterator.next();
2012-07-29 09:33:13 +02:00
playerinstance.a();
2012-11-06 13:05:28 +01:00
iterator.remove();
}
2012-11-06 13:05:28 +01:00
// CraftBukkit end
2013-03-25 05:22:32 +01:00
// this.d.clear(); // CraftBukkit - Removals are already covered
2012-01-12 23:10:13 +01:00
if (this.managedPlayers.isEmpty()) {
2013-03-25 05:22:32 +01:00
if (!wasNotEmpty) return; // CraftBukkit - Only do unload when we go from non-empty to empty
2012-07-29 09:33:13 +02:00
WorldProvider worldprovider = this.world.worldProvider;
2012-01-12 23:10:13 +01:00
2012-07-29 09:33:13 +02:00
if (!worldprovider.e()) {
this.world.chunkProviderServer.a();
2012-01-12 23:10:13 +01:00
}
// CraftBukkit start
wasNotEmpty = false;
} else {
wasNotEmpty = true;
2012-01-12 23:10:13 +01:00
}
// CraftBukkit end
}
2012-12-20 05:03:52 +01:00
private PlayerChunk a(int i, int j, boolean flag) {
long k = (long) i + 2147483647L | (long) j + 2147483647L << 32;
2012-12-20 05:03:52 +01:00
PlayerChunk playerchunk = (PlayerChunk) this.c.getEntry(k);
2012-12-20 05:03:52 +01:00
if (playerchunk == null && flag) {
playerchunk = new PlayerChunk(this, i, j);
this.c.put(k, playerchunk);
}
2012-12-20 05:03:52 +01:00
return playerchunk;
}
// CraftBukkit start
public final boolean isChunkInUse(int x, int z) {
2012-12-20 05:03:52 +01:00
PlayerChunk pi = a(x, z, false);
if (pi != null) {
2012-12-20 05:03:52 +01:00
return (PlayerChunk.b(pi).size() > 0);
}
return false;
}
// CraftBukkit end
public void flagDirty(int i, int j, int k) {
int l = i >> 4;
int i1 = k >> 4;
2012-12-20 05:03:52 +01:00
PlayerChunk playerchunk = this.a(l, i1, false);
2012-12-20 05:03:52 +01:00
if (playerchunk != null) {
playerchunk.a(i & 15, j, k & 15);
}
}
public void addPlayer(EntityPlayer entityplayer) {
int i = (int) entityplayer.locX >> 4;
int j = (int) entityplayer.locZ >> 4;
entityplayer.d = entityplayer.locX;
entityplayer.e = entityplayer.locZ;
2012-07-29 09:33:13 +02:00
2013-03-25 05:22:32 +01:00
// CraftBukkit start - Load nearby chunks first
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.
2012-11-30 09:49:19 +01:00
List<ChunkCoordIntPair> chunkList = new LinkedList<ChunkCoordIntPair>();
2012-07-29 09:33:13 +02:00
for (int k = i - this.e; k <= i + this.e; ++k) {
for (int l = j - this.e; l <= j + this.e; ++l) {
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.
2012-11-30 09:49:19 +01:00
chunkList.add(new ChunkCoordIntPair(k, l));
2012-07-29 09:33:13 +02:00
}
}
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.
2012-11-30 09:49:19 +01:00
Collections.sort(chunkList, new ChunkCoordComparator(entityplayer));
for (ChunkCoordIntPair pair : chunkList) {
this.a(pair.x, pair.z, true).a(entityplayer);
}
// CraftBukkit end
2012-07-29 09:33:13 +02:00
this.managedPlayers.add(entityplayer);
this.b(entityplayer);
}
public void b(EntityPlayer entityplayer) {
ArrayList arraylist = new ArrayList(entityplayer.chunkCoordIntPairQueue);
int i = 0;
int j = this.e;
int k = (int) entityplayer.locX >> 4;
int l = (int) entityplayer.locZ >> 4;
2011-02-23 03:37:56 +01:00
int i1 = 0;
2011-05-26 14:48:22 +02:00
int j1 = 0;
2012-12-20 05:03:52 +01:00
ChunkCoordIntPair chunkcoordintpair = PlayerChunk.a(this.a(k, l, true));
2012-07-29 09:33:13 +02:00
entityplayer.chunkCoordIntPairQueue.clear();
if (arraylist.contains(chunkcoordintpair)) {
entityplayer.chunkCoordIntPairQueue.add(chunkcoordintpair);
}
2011-05-26 14:48:22 +02:00
int k1;
2012-07-29 09:33:13 +02:00
for (k1 = 1; k1 <= j * 2; ++k1) {
2011-05-26 14:48:22 +02:00
for (int l1 = 0; l1 < 2; ++l1) {
2012-07-29 09:33:13 +02:00
int[] aint = this.f[i++ % 4];
2011-05-26 14:48:22 +02:00
for (int i2 = 0; i2 < k1; ++i2) {
i1 += aint[0];
j1 += aint[1];
2012-12-20 05:03:52 +01:00
chunkcoordintpair = PlayerChunk.a(this.a(k + i1, l + j1, true));
2012-07-29 09:33:13 +02:00
if (arraylist.contains(chunkcoordintpair)) {
entityplayer.chunkCoordIntPairQueue.add(chunkcoordintpair);
}
}
}
}
2012-07-29 09:33:13 +02:00
i %= 4;
2011-02-23 03:37:56 +01:00
2012-07-29 09:33:13 +02:00
for (k1 = 0; k1 < j * 2; ++k1) {
i1 += this.f[i][0];
j1 += this.f[i][1];
2012-12-20 05:03:52 +01:00
chunkcoordintpair = PlayerChunk.a(this.a(k + i1, l + j1, true));
2012-07-29 09:33:13 +02:00
if (arraylist.contains(chunkcoordintpair)) {
entityplayer.chunkCoordIntPairQueue.add(chunkcoordintpair);
}
}
}
public void removePlayer(EntityPlayer entityplayer) {
int i = (int) entityplayer.d >> 4;
int j = (int) entityplayer.e >> 4;
2012-07-29 09:33:13 +02:00
for (int k = i - this.e; k <= i + this.e; ++k) {
for (int l = j - this.e; l <= j + this.e; ++l) {
2012-12-20 05:03:52 +01:00
PlayerChunk playerchunk = this.a(k, l, false);
2012-12-20 05:03:52 +01:00
if (playerchunk != null) {
playerchunk.b(entityplayer);
}
}
}
this.managedPlayers.remove(entityplayer);
}
2012-07-29 09:33:13 +02:00
private boolean a(int i, int j, int k, int l, int i1) {
int j1 = i - k;
int k1 = j - l;
2012-07-29 09:33:13 +02:00
return j1 >= -i1 && j1 <= i1 ? k1 >= -i1 && k1 <= i1 : false;
}
public void movePlayer(EntityPlayer entityplayer) {
int i = (int) entityplayer.locX >> 4;
int j = (int) entityplayer.locZ >> 4;
double d0 = entityplayer.d - entityplayer.locX;
double d1 = entityplayer.e - entityplayer.locZ;
double d2 = d0 * d0 + d1 * d1;
if (d2 >= 64.0D) {
int k = (int) entityplayer.d >> 4;
int l = (int) entityplayer.e >> 4;
2012-07-29 09:33:13 +02:00
int i1 = this.e;
int j1 = i - k;
int k1 = j - l;
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.
2012-11-30 09:49:19 +01:00
List<ChunkCoordIntPair> chunksToLoad = new LinkedList<ChunkCoordIntPair>(); // CraftBukkit
2012-07-29 09:33:13 +02:00
if (j1 != 0 || k1 != 0) {
for (int l1 = i - i1; l1 <= i + i1; ++l1) {
for (int i2 = j - i1; i2 <= j + i1; ++i2) {
if (!this.a(l1, i2, k, l, i1)) {
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.
2012-11-30 09:49:19 +01:00
chunksToLoad.add(new ChunkCoordIntPair(l1, i2)); // CraftBukkit
}
2012-07-29 09:33:13 +02:00
if (!this.a(l1 - j1, i2 - k1, i, j, i1)) {
2012-12-20 05:03:52 +01:00
PlayerChunk playerchunk = this.a(l1 - j1, i2 - k1, false);
2012-12-20 05:03:52 +01:00
if (playerchunk != null) {
playerchunk.b(entityplayer);
}
}
}
}
2012-07-29 09:33:13 +02:00
this.b(entityplayer);
entityplayer.d = entityplayer.locX;
entityplayer.e = entityplayer.locZ;
2011-06-08 23:00:30 +02:00
// CraftBukkit start - send nearest chunks first
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.
2012-11-30 09:49:19 +01:00
Collections.sort(chunksToLoad, new ChunkCoordComparator(entityplayer));
for (ChunkCoordIntPair pair : chunksToLoad) {
this.a(pair.x, pair.z, true).a(entityplayer);
}
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.
2012-11-30 09:49:19 +01:00
if (i1 > 1 || i1 < -1 || j1 > 1 || j1 < -1) {
Collections.sort(entityplayer.chunkCoordIntPairQueue, new ChunkCoordComparator(entityplayer));
2011-06-08 23:00:30 +02:00
}
// CraftBukkit end
}
}
}
2012-07-29 09:33:13 +02:00
public boolean a(EntityPlayer entityplayer, int i, int j) {
2012-12-20 05:03:52 +01:00
PlayerChunk playerchunk = this.a(i, j, false);
2012-07-29 09:33:13 +02:00
2012-12-20 05:03:52 +01:00
return playerchunk == null ? false : PlayerChunk.b(playerchunk).contains(entityplayer) && !entityplayer.chunkCoordIntPairQueue.contains(PlayerChunk.a(playerchunk));
}
2012-07-29 09:33:13 +02:00
public static int getFurthestViewableBlock(int i) {
return i * 16 - 16;
}
2012-12-20 05:03:52 +01:00
static WorldServer a(PlayerChunkMap playerchunkmap) {
return playerchunkmap.world;
2012-07-29 09:33:13 +02:00
}
2012-12-20 05:03:52 +01:00
static LongHashMap b(PlayerChunkMap playerchunkmap) {
return playerchunkmap.c;
}
2012-07-29 09:33:13 +02:00
2012-12-20 05:03:52 +01:00
static Queue c(PlayerChunkMap playermanager) { // CraftBukkit List -> Queue
2012-07-29 09:33:13 +02:00
return playermanager.d;
}
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.
2012-11-30 09:49:19 +01:00
2013-03-25 05:22:32 +01:00
// CraftBukkit start - Sorter to load nearby chunks first
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.
2012-11-30 09:49:19 +01:00
private static class ChunkCoordComparator implements java.util.Comparator<ChunkCoordIntPair> {
private int x;
private int z;
public ChunkCoordComparator (EntityPlayer entityplayer) {
x = (int) entityplayer.locX >> 4;
z = (int) entityplayer.locZ >> 4;
}
public int compare(ChunkCoordIntPair a, ChunkCoordIntPair b) {
if (a.equals(b)) {
return 0;
}
// Subtract current position to set center point
int ax = a.x - this.x;
int az = a.z - this.z;
int bx = b.x - this.x;
int bz = b.z - this.z;
int result = ((ax - bx) * (ax + bx)) + ((az - bz) * (az + bz));
if (result != 0) {
return result;
}
if (ax < 0) {
if (bx < 0) {
return bz - az;
} else {
return -1;
}
} else {
if (bx < 0) {
return 1;
} else {
return az - bz;
}
}
}
}
// CraftBukkit end
}