SteamWar/Paper
13
0
Fork 0
geforkt von Mirrors/Paper
Code Issues Pull-Requests 1 Projekte Releases Wiki Aktivität
f275e9cb9c
Paper/Spigot-Server-Patches/0460-Speed-up-processing-of-chunk-loads-and-generation.patch

219 Zeilen
11 KiB
Diff
Originalformat Normale Ansicht Verlauf

Revert "Re-track players that dismount from other players"
2020-04-22 00:06:30 +02:00
From 7014d349d3e52fe0aa58f9d2b6b72d2675396332 Mon Sep 17 00:00:00 2001
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
From: Aikar <aikar@aikar.co>
Date: Thu, 9 Apr 2020 00:09:26 -0400
Subject: [PATCH] Speed up processing of chunk loads and generation
Credit to Spotted for the idea
A lot of the new chunk system requires constant back and forth the main thread
to handle priority scheduling and ensuring conflicting tasks do not run at the
same time.
The issue is, these queues are only checked at either:
A) Sync Chunk Loads
B) End of Tick while sleeping
This results in generating chunks sitting waiting for a full tick to
complete before it will even start the next unit of work to do.
Additionally, this also delays loading of chunks until this same timing.
We will now periodically poll the chunk task queues throughout the tick,
looking for work to do.
We do this in a fair method that considers all worlds, not just the one being
ticked, so that each world can get 1 task procesed each before the next pass.
We also cap the throughput of these task processes to 1 per world per 0.1ms or
200 max per tick, to ensure that high volume of tasks do not overload the current
tick time.
In a view distance of 15, chunk loading performance was visually faster on the client.
Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
diff --git a/src/main/java/co/aikar/timings/MinecraftTimings.java b/src/main/java/co/aikar/timings/MinecraftTimings.java
Revert "Re-track players that dismount from other players"
2020-04-22 00:06:30 +02:00
index 69e26a82..434833d5 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
--- a/src/main/java/co/aikar/timings/MinecraftTimings.java
+++ b/src/main/java/co/aikar/timings/MinecraftTimings.java
@@ -13,6 +13,7 @@ import java.util.Map;
public final class MinecraftTimings {
public static final Timing serverOversleep = Timings.ofSafe("Server Oversleep");
+ public static final Timing midTickChunkTasks = Timings.ofSafe("Mid Tick Chunk Tasks");
public static final Timing playerListTimer = Timings.ofSafe("Player List");
public static final Timing commandFunctionsTimer = Timings.ofSafe("Command Functions");
public static final Timing connectionTimer = Timings.ofSafe("Connection Handler");
diff --git a/src/main/java/net/minecraft/server/ChunkProviderServer.java b/src/main/java/net/minecraft/server/ChunkProviderServer.java
Revert "Re-track players that dismount from other players"
2020-04-22 00:06:30 +02:00
index 1c0a7f40..4af75a95 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
--- a/src/main/java/net/minecraft/server/ChunkProviderServer.java
+++ b/src/main/java/net/minecraft/server/ChunkProviderServer.java
Improve async login (#3189) Add helper functions to ChunkProviderServer to make this easier for other uses Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
2020-04-19 19:58:02 +02:00
@@ -681,6 +681,7 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
this.world.getMethodProfiler().enter("purge");
this.world.timings.doChunkMap.startTiming(); // Spigot
this.chunkMapDistance.purgeTickets();
+ this.world.getMinecraftServer().midTickLoadChunks(); // Paper
this.tickDistanceManager();
this.world.timings.doChunkMap.stopTiming(); // Spigot
this.world.getMethodProfiler().exitEnter("chunks");
Improve async login (#3189) Add helper functions to ChunkProviderServer to make this easier for other uses Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
2020-04-19 19:58:02 +02:00
@@ -690,6 +691,7 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
this.world.timings.doChunkUnload.startTiming(); // Spigot
this.world.getMethodProfiler().exitEnter("unload");
this.playerChunkMap.unloadChunks(booleansupplier);
+ this.world.getMinecraftServer().midTickLoadChunks(); // Paper
this.world.timings.doChunkUnload.stopTiming(); // Spigot
this.world.getMethodProfiler().exit();
this.clearCache();
Improve async login (#3189) Add helper functions to ChunkProviderServer to make this easier for other uses Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
2020-04-19 19:58:02 +02:00
@@ -748,7 +750,7 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
entityPlayer.playerNaturallySpawnedEvent.callEvent();
};
// Paper end
- this.playerChunkMap.forEachVisibleChunk((playerchunk) -> { // Paper - safe iterator incase chunk loads, also no wrapping
+ final int[] chunksTicked = {0}; this.playerChunkMap.forEachVisibleChunk((playerchunk) -> { // Paper - safe iterator incase chunk loads, also no wrapping
Optional<Chunk> optional = ((Either) playerchunk.b().getNow(PlayerChunk.UNLOADED_CHUNK)).left();
if (optional.isPresent()) {
Improve async login (#3189) Add helper functions to ChunkProviderServer to make this easier for other uses Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
2020-04-19 19:58:02 +02:00
@@ -831,6 +833,7 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
this.world.timings.chunkTicks.startTiming(); // Spigot // Paper
this.world.a(chunk, k);
this.world.timings.chunkTicks.stopTiming(); // Spigot // Paper
+ if (chunksTicked[0]++ % 10 == 0) this.world.getMinecraftServer().midTickLoadChunks(); // Paper
}
}
});
Improve async login (#3189) Add helper functions to ChunkProviderServer to make this easier for other uses Co-authored-by: Spottedleaf <Spottedleaf@users.noreply.github.com>
2020-04-19 19:58:02 +02:00
@@ -972,6 +975,38 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
super.executeTask(runnable);
}
+ // Paper start
+ private long lastChunkTask = 0;
+ public void midTickLoadChunks() {
+ MinecraftServer server = ChunkProviderServer.this.world.getMinecraftServer();
+ try (co.aikar.timings.Timing ignored = co.aikar.timings.MinecraftTimings.midTickChunkTasks.startTiming()) {
+ while (server.canSleepForTick()) {
+ try {
+ // always try to load chunks as long as we aren't falling behind, restrain generation/other updates only.
+ boolean execChunkTask = com.destroystokyo.paper.io.chunk.ChunkTaskManager.pollChunkWaitQueue() || ChunkProviderServer.this.world.asyncChunkTaskManager.pollNextChunkTask(); // Paper
Fix issues with 167 causing crashes due to missing chunks - Fixes #3122 Forgot to flip the pending boolean back to false, causing it to copy empty data on the next tick if nothing else triggered a load. haven't managed to actually reproduce the crash others got, but did verify that the bad copy was occurring erasing the data. also fixed a bug with chunk load callback not executing before another one was scheduled.
2020-04-10 20:11:46 +02:00
+ if (ChunkProviderServer.this.tickDistanceManager() || execChunkTask) {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
+ continue;
+ }
+ long now = System.nanoTime();
+ // cap to 1 task every 0.1ms per world and max 200 tasks per tick.
+ // Anything that doesn't make it past this can load during sleep
+ // we do not want to use this.executeNext as that also processes chunk loads and might count against task counter.
+ // We also have already ticked the distance manager above too.
+ if (server.chunksTasksRan < 200 && now - lastChunkTask > 100000 && super.executeNext()) {
+ ChunkProviderServer.this.lightEngine.queueUpdate();
+ server.chunksTasksRan++;
+ lastChunkTask = now;
+ }
+ break;
+ } finally {
+ // from below: process pending Chunk loadCallback() and unloadCallback() after each run task
+ playerChunkMap.callbackExecutor.run();
+ }
+ }
+ }
+ }
+ // Paper end
+
@Override
protected boolean executeNext() {
// CraftBukkit start - process pending Chunk loadCallback() and unloadCallback() after each run task
diff --git a/src/main/java/net/minecraft/server/MinecraftServer.java b/src/main/java/net/minecraft/server/MinecraftServer.java
Revert "Re-track players that dismount from other players"
2020-04-22 00:06:30 +02:00
index e35bacac..2f424e6e 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
--- a/src/main/java/net/minecraft/server/MinecraftServer.java
+++ b/src/main/java/net/minecraft/server/MinecraftServer.java
Load Spawn Chunks Asynchronously and Spiral Out Ensures absolute center is first in priority Speeds up server startup
2020-04-19 12:01:07 +02:00
@@ -907,6 +907,7 @@ public abstract class MinecraftServer extends IAsyncTaskHandlerReentrant<TickTas
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
// Paper end
tickSection = curTime;
}
+ chunksTasksRan = 0; // Paper
// Spigot end
//MinecraftServer.currentTick = (int) (System.currentTimeMillis() / 50); // CraftBukkit // Paper - don't overwrite current tick time
Load Spawn Chunks Asynchronously and Spiral Out Ensures absolute center is first in priority Speeds up server startup
2020-04-19 12:01:07 +02:00
@@ -977,7 +978,7 @@ public abstract class MinecraftServer extends IAsyncTaskHandlerReentrant<TickTas
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
}
- private boolean canSleepForTick() {
+ public boolean canSleepForTick() { // Paper
// CraftBukkit start
return this.forceTicks || this.isEntered() || SystemUtils.getMonotonicMillis() < (this.ac ? this.ab : this.nextTick);
}
Load Spawn Chunks Asynchronously and Spiral Out Ensures absolute center is first in priority Speeds up server startup
2020-04-19 12:01:07 +02:00
@@ -1005,6 +1006,20 @@ public abstract class MinecraftServer extends IAsyncTaskHandlerReentrant<TickTas
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
});
}
+ // Paper start
+ public int chunksTasksRan = 0;
+ public void midTickLoadChunks() {
+ if (!this.canSleepForTick()) {
+ return;
+ }
+
+ Iterator<WorldServer> iterator = this.getWorlds().iterator();
+ while (this.canSleepForTick() && iterator.hasNext()) {
+ iterator.next().getChunkProvider().serverThreadQueue.midTickLoadChunks();
+ }
+ }
+ // Paper end
+
@Override
protected TickTask postToMainThread(Runnable runnable) {
return new TickTask(this.ticks, runnable);
diff --git a/src/main/java/net/minecraft/server/PlayerChunkMap.java b/src/main/java/net/minecraft/server/PlayerChunkMap.java
Revert "Re-track players that dismount from other players"
2020-04-22 00:06:30 +02:00
index e61ddeb1..92c9ab43 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
--- a/src/main/java/net/minecraft/server/PlayerChunkMap.java
+++ b/src/main/java/net/minecraft/server/PlayerChunkMap.java
Fix issues with 167 causing crashes due to missing chunks - Fixes #3122 Forgot to flip the pending boolean back to false, causing it to copy empty data on the next tick if nothing else triggered a load. haven't managed to actually reproduce the crash others got, but did verify that the bad copy was occurring erasing the data. also fixed a bug with chunk load callback not executing before another one was scheduled.
2020-04-10 20:11:46 +02:00
@@ -793,7 +793,7 @@ public class PlayerChunkMap extends IChunkLoader implements PlayerChunk.d {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
CompletableFuture<Either<IChunkAccess, PlayerChunk.Failure>> ret = new CompletableFuture<>();
Consumer<ChunkRegionLoader.InProgressChunkHolder> chunkHolderConsumer = (ChunkRegionLoader.InProgressChunkHolder holder) -> {
- PlayerChunkMap.this.executor.addTask(() -> {
+ com.destroystokyo.paper.io.chunk.ChunkTaskManager.queueChunkWaitTask(() -> {
ret.complete(syncLoadComplete.apply(holder, null));
});
};
diff --git a/src/main/java/net/minecraft/server/WorldServer.java b/src/main/java/net/minecraft/server/WorldServer.java
Revert "Re-track players that dismount from other players"
2020-04-22 00:06:30 +02:00
index 969c6aad..4b9b79a9 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
--- a/src/main/java/net/minecraft/server/WorldServer.java
+++ b/src/main/java/net/minecraft/server/WorldServer.java
@@ -420,6 +420,7 @@ public class WorldServer extends World {
}
timings.scheduledBlocks.stopTiming(); // Spigot
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
gameprofilerfiller.exitEnter("raid");
this.timings.raids.startTiming(); // Paper - timings
this.persistentRaid.a();
@@ -432,6 +433,7 @@ public class WorldServer extends World {
timings.doSounds.startTiming(); // Spigot
this.ad();
timings.doSounds.stopTiming(); // Spigot
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
this.ticking = false;
gameprofilerfiller.exitEnter("entities");
boolean flag3 = true || !this.players.isEmpty() || !this.getForceLoadedChunks().isEmpty(); // CraftBukkit - this prevents entity cleanup, other issues on servers with no players
Delay unsafe actions until after entity ticking is done - Fixes #3114 This will help prevent many cases of unregistering entities during entity ticking Currently delays Chunk Unloads and Async Chunk load callbacks Also dropped mid ticking chunk tasks during entity ticking to reduce this risk
2020-04-12 03:31:40 +02:00
@@ -517,6 +519,7 @@ public class WorldServer extends World {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
timings.entityTick.stopTiming(); // Spigot
this.tickingEntities = false;
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
try (co.aikar.timings.Timing ignored = this.timings.newEntities.startTiming()) { // Paper - timings
while ((entity = (Entity) this.entitiesToAdd.poll()) != null) {
Delay unsafe actions until after entity ticking is done - Fixes #3114 This will help prevent many cases of unregistering entities during entity ticking Currently delays Chunk Unloads and Async Chunk load callbacks Also dropped mid ticking chunk tasks during entity ticking to reduce this risk
2020-04-12 03:31:40 +02:00
@@ -527,7 +530,9 @@ public class WorldServer extends World {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
gameprofilerfiller.exit();
timings.tickEntities.stopTiming(); // Spigot
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
this.tickBlockEntities();
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
}
gameprofilerfiller.exit();
--
Revert "Re-track players that dismount from other players"
2020-04-22 00:06:30 +02:00
2.25.1.windows.1
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 08:25:18 +02:00
In neuem Issue referenzieren Permalink kopieren