mirrors/papermc
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
papermc/Spigot-Server-Patches/0460-Mid-Tick-Chunk-Tasks-Speed-up-processing-of-chunk-lo.patch

267 lines
13 KiB
Diff
Raw Normal View History

Clean up Timings and Async Chunk Configs Renames a bunch of timings to be more appropriate for the new environment. Many things dealt with sync loads which wasn't correct anymore. adjusted timings to be a little bit more accurate here. Also cleaned up old 1.13 async chunks configs so people won't keep thinking they can change some of those configs when they can't.
2020-04-26 06:05:41 +00:00
From 815a77a6e4431669b2b8bc9d1fefd5735403d6c5 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 06:25:18 +00:00
From: Aikar <aikar@aikar.co>
Date: Thu, 9 Apr 2020 00:09:26 -0400
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
Subject: [PATCH] Mid Tick Chunk Tasks - Speed up processing of chunk loads and
generation
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 06:25:18 +00:00
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.
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
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
index 223d3b1125..37341d2d2e 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 06:25:18 +00: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");
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
diff --git a/src/main/java/com/destroystokyo/paper/PaperConfig.java b/src/main/java/com/destroystokyo/paper/PaperConfig.java
Clean up Timings and Async Chunk Configs Renames a bunch of timings to be more appropriate for the new environment. Many things dealt with sync loads which wasn't correct anymore. adjusted timings to be a little bit more accurate here. Also cleaned up old 1.13 async chunks configs so people won't keep thinking they can change some of those configs when they can't.
2020-04-26 06:05:41 +00:00
index f4836e2da1..a6107ba016 100644
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
--- a/src/main/java/com/destroystokyo/paper/PaperConfig.java
+++ b/src/main/java/com/destroystokyo/paper/PaperConfig.java
Clean up Timings and Async Chunk Configs Renames a bunch of timings to be more appropriate for the new environment. Many things dealt with sync loads which wasn't correct anymore. adjusted timings to be a little bit more accurate here. Also cleaned up old 1.13 async chunks configs so people won't keep thinking they can change some of those configs when they can't.
2020-04-26 06:05:41 +00:00
@@ -414,4 +414,9 @@ public class PaperConfig {
log("Async Chunks: Enabled - Chunks will be loaded much faster, without lag.");
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
}
}
+
+ public static int midTickChunkTasks = 1000;
+ private static void midTickChunkTasks() {
+ midTickChunkTasks = getInt("settings.chunk-tasks-per-tick", midTickChunkTasks);
+ }
}
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 06:25:18 +00:00
diff --git a/src/main/java/net/minecraft/server/ChunkProviderServer.java b/src/main/java/net/minecraft/server/ChunkProviderServer.java
Clean up Timings and Async Chunk Configs Renames a bunch of timings to be more appropriate for the new environment. Many things dealt with sync loads which wasn't correct anymore. adjusted timings to be a little bit more accurate here. Also cleaned up old 1.13 async chunks configs so people won't keep thinking they can change some of those configs when they can't.
2020-04-26 06:05:41 +00:00
index c457e3b772..747305619b 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 06:25:18 +00:00
--- a/src/main/java/net/minecraft/server/ChunkProviderServer.java
+++ b/src/main/java/net/minecraft/server/ChunkProviderServer.java
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
@@ -683,6 +683,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 06:25:18 +00: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 so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
@@ -692,6 +693,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 06:25:18 +00: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 so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
@@ -750,7 +752,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 06:25:18 +00: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 so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
@@ -833,6 +835,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 06:25:18 +00: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 mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
@@ -974,6 +977,41 @@ 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 06:25:18 +00:00
super.executeTask(runnable);
}
+ // Paper start
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
+ private long lastMidTickChunkTask = 0;
+ public boolean pollChunkLoadTasks() {
+ if (com.destroystokyo.paper.io.chunk.ChunkTaskManager.pollChunkWaitQueue() || ChunkProviderServer.this.world.asyncChunkTaskManager.pollNextChunkTask()) {
+ try {
+ ChunkProviderServer.this.tickDistanceManager();
+ } finally {
+ // from below: process pending Chunk loadCallback() and unloadCallback() after each run task
+ playerChunkMap.callbackExecutor.run();
+ }
+ return true;
+ }
+ return false;
+ }
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 06:25:18 +00:00
+ public void midTickLoadChunks() {
+ MinecraftServer server = ChunkProviderServer.this.world.getMinecraftServer();
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
+ // always try to load chunks, restrain generation/other updates only. don't count these towards tick count
+ //noinspection StatementWithEmptyBody
+ while (pollChunkLoadTasks()) {}
+
+ if (System.nanoTime() - lastMidTickChunkTask < 1000000) {
+ return;
+ }
+
+ for (;server.midTickChunksTasksRan < com.destroystokyo.paper.PaperConfig.midTickChunkTasks && server.canSleepForTick();) {
+ if (this.executeNext()) {
+ server.midTickChunksTasksRan++;
+ lastMidTickChunkTask = System.nanoTime();
+ } else {
+ break;
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 06:25:18 +00:00
+ }
+ }
+ }
+ // 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
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
index 77adc64e30..3c25436f15 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 06:25:18 +00: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 10:01:07 +00: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 06:25:18 +00:00
// Paper end
tickSection = curTime;
}
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
+ midTickChunksTasksRan = 0; // Paper
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 06:25:18 +00:00
// 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 10:01:07 +00: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 06:25:18 +00:00
}
- private boolean canSleepForTick() {
+ public boolean canSleepForTick() { // Paper
// CraftBukkit start
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
if (isOversleep) return canOversleep();// Paper - because of our changes, this logic is broken
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 06:25:18 +00:00
return this.forceTicks || this.isEntered() || SystemUtils.getMonotonicMillis() < (this.ac ? this.ab : this.nextTick);
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
@@ -1007,6 +1008,23 @@ 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 06:25:18 +00:00
});
}
+ // Paper start
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
+ public int midTickChunksTasksRan = 0;
+ private long midTickLastRan = 0;
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 06:25:18 +00:00
+ public void midTickLoadChunks() {
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
+ if (!isMainThread() || System.nanoTime() - midTickLastRan < 250000) {
+ // only check once per 0.25ms incase this code is called in a hot method
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 06:25:18 +00:00
+ return;
+ }
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
+ try (co.aikar.timings.Timing ignored = co.aikar.timings.MinecraftTimings.midTickChunkTasks.startTiming()) {
+ for (WorldServer value : this.getWorlds()) {
+ value.getChunkProvider().serverThreadQueue.midTickLoadChunks();
+ }
+ midTickLastRan = System.nanoTime();
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 06:25:18 +00:00
+ }
+ }
+ // Paper end
+
@Override
protected TickTask postToMainThread(Runnable runnable) {
return new TickTask(this.ticks, runnable);
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
@@ -1093,6 +1111,7 @@ public abstract class MinecraftServer extends IAsyncTaskHandlerReentrant<TickTas
// Paper start - move oversleep into full server tick
isOversleep = true;MinecraftTimings.serverOversleep.startTiming();
this.awaitTasks(() -> {
+ midTickLoadChunks(); // will only do loads since we are still considered !canSleepForTick
return !this.canOversleep();
});
isOversleep = false;MinecraftTimings.serverOversleep.stopTiming();
@@ -1175,13 +1194,16 @@ 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 06:25:18 +00:00
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
protected void b(BooleanSupplier booleansupplier) {
+ midTickLoadChunks(); // Paper
MinecraftTimings.bukkitSchedulerTimer.startTiming(); // Spigot // Paper
this.server.getScheduler().mainThreadHeartbeat(this.ticks); // CraftBukkit
MinecraftTimings.bukkitSchedulerTimer.stopTiming(); // Spigot // Paper
+ midTickLoadChunks(); // Paper
this.methodProfiler.enter("commandFunctions");
MinecraftTimings.commandFunctionsTimer.startTiming(); // Spigot // Paper
this.getFunctionData().tick();
MinecraftTimings.commandFunctionsTimer.stopTiming(); // Spigot // Paper
+ midTickLoadChunks(); // Paper
this.methodProfiler.exitEnter("levels");
Iterator iterator = this.getWorlds().iterator();
@@ -1192,7 +1214,7 @@ public abstract class MinecraftServer extends IAsyncTaskHandlerReentrant<TickTas
processQueue.remove().run();
}
MinecraftTimings.processQueueTimer.stopTiming(); // Spigot
-
+ midTickLoadChunks(); // Paper
MinecraftTimings.timeUpdateTimer.startTiming(); // Spigot // Paper
// Send time updates to everyone, it will get the right time from the world the player is in.
// Paper start - optimize time updates
@@ -1235,9 +1257,11 @@ public abstract class MinecraftServer extends IAsyncTaskHandlerReentrant<TickTas
this.methodProfiler.enter("tick");
try {
+ midTickLoadChunks(); // Paper
worldserver.timings.doTick.startTiming(); // Spigot
worldserver.doTick(booleansupplier);
worldserver.timings.doTick.stopTiming(); // Spigot
+ midTickLoadChunks(); // Paper
} catch (Throwable throwable) {
// Spigot Start
CrashReport crashreport;
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 06:25:18 +00:00
diff --git a/src/main/java/net/minecraft/server/WorldServer.java b/src/main/java/net/minecraft/server/WorldServer.java
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
index 142770bcd6..3f62fe2bb1 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 06:25:18 +00: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 01:31:40 +00: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 06:25:18 +00: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) {
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
@@ -527,6 +530,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 06:25:18 +00:00
gameprofilerfiller.exit();
timings.tickEntities.stopTiming(); // Spigot
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
this.tickBlockEntities();
}
--
Improve mid tick chunk loading, Fix Oversleep, other improvements Process loads outside of any canSleep check. Original intent was to only apply those restrictions to generations but realized I had some checks higher up the call chain. Reworked the back off strategy to just run every 1 millisecond per world, and to apply the per tick limit to generations only. This guarantees that your chunk will load with at most around 1ms delay. Additionally, fire midTick processing in a few more places, notably the oversleep section so we can keep processing loads here too which has a large up to 50ms window... Speaking of oversleep, we had a bug in our implementation changes for Timings that caused oversleep to not sleep the correct amount. Because we now moved it into the NEXT tick instead of THIS tick, the value of nextTick had already been increased to +50ms, resulting in the risk of sleeping more than it should, but, more importantly, this caused every task that was trying to NOT run during oversleep to actually run during oversleep. This is now fixed. Another small tweak is to the /tps command, to no longer show the star when TPS is right at 20. Due to ineffeciencies in the sleep precision, TPS is commonly 20.02. This causes the star to show up almost constantly, so now only show it if we actually hit a real "catchup". This commit also improves the changes to the CallbackExecutor, in that it now is also recursion safe. It was possible that the executor could run tasks out of desired order if the executor task scheduled more executor tasks. We solve this by ensuring new additions do not enter the currently iterated queue. Each depth level will have its own queue. Fixes #3220
2020-04-26 03:47:29 +00:00
2.26.2
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 06:25:18 +00:00
Reference in a new issue Copy permalink