SteamWar/Paper
13
0
Fork 0
geforkt von Mirrors/Paper
Code Issues Pull-Requests Projekte Releases Wiki Aktivität
f860969175
Paper/Spigot-Server-Patches/0445-Optimise-Chunk-getFluid.patch

63 Zeilen
2.8 KiB
Diff
Originalformat Normale Ansicht Verlauf

Rebuild all patches using the new rebuild pattern
2020-05-06 11:48:49 +02:00
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
Optimise Chunk#getFluid (#2860) Removing the try catch and generally reducing ops should make it faster on its own, however removing the try catch makes it easier to inline due to code size
2020-03-18 13:21:35 +01:00
From: Spottedleaf <Spottedleaf@users.noreply.github.com>
Date: Tue, 14 Jan 2020 14:59:08 -0800
Subject: [PATCH] Optimise Chunk#getFluid
Removing the try catch and generally reducing ops should make it
faster on its own, however removing the try catch makes it
easier to inline due to code size
diff --git a/src/main/java/net/minecraft/server/Chunk.java b/src/main/java/net/minecraft/server/Chunk.java
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 07:25:11 +02:00
index cfdf6ea55dedeaf6b96566b72ca0015350c13e92..74d110874d0a9c1603d6b2d77753179ba49811ea 100644
Optimise Chunk#getFluid (#2860) Removing the try catch and generally reducing ops should make it faster on its own, however removing the try catch makes it easier to inline due to code size
2020-03-18 13:21:35 +01:00
--- a/src/main/java/net/minecraft/server/Chunk.java
+++ b/src/main/java/net/minecraft/server/Chunk.java
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 07:25:11 +02:00
@@ -385,17 +385,20 @@ public class Chunk implements IChunkAccess {
Optimise Chunk#getFluid (#2860) Removing the try catch and generally reducing ops should make it faster on its own, however removing the try catch makes it easier to inline due to code size
2020-03-18 13:21:35 +01:00
}
public Fluid a(int i, int j, int k) {
- try {
- if (j >= 0 && j >> 4 < this.sections.length) {
- ChunkSection chunksection = this.sections[j >> 4];
-
- if (!ChunkSection.a(chunksection)) {
- return chunksection.b(i & 15, j & 15, k & 15);
+ //try { // Paper - remove try catch
+ // Paper start - reduce the number of ops in this call
+ int index = j >> 4;
+ if (index >= 0 && index < this.sections.length) {
+ ChunkSection chunksection = this.sections[index];
+
+ if (chunksection != null) {
+ return chunksection.blockIds.a((j & 15) << 8 | (k & 15) << 4 | i & 15).getFluid();
}
+ // Paper end
}
return FluidTypes.EMPTY.h();
- } catch (Throwable throwable) {
+ /*} catch (Throwable throwable) { // Paper - remove try catch
CrashReport crashreport = CrashReport.a(throwable, "Getting fluid state");
CrashReportSystemDetails crashreportsystemdetails = crashreport.a("Block being got");
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 07:25:11 +02:00
@@ -404,6 +407,7 @@ public class Chunk implements IChunkAccess {
Optimise Chunk#getFluid (#2860) Removing the try catch and generally reducing ops should make it faster on its own, however removing the try catch makes it easier to inline due to code size
2020-03-18 13:21:35 +01:00
});
throw new ReportedException(crashreport);
}
+ */ // Paper - remove try catch
}
// CraftBukkit start
diff --git a/src/main/java/net/minecraft/server/ChunkSection.java b/src/main/java/net/minecraft/server/ChunkSection.java
Optimize Light Engine Massive update to light to improve performance and chunk loading/generation. 1) Massive bit packing/unpacking optimizations and inlining. A lot of performance has to do with constant packing and unpacking of bits. We now inline a most bit operations, and re-use base x/y/z bits in many places. This helps with cpu level processing to just do all the math at once instead of having to jump in and out of function calls. This much logic also is likely over the JVM Inline limit for JIT too. 2) Applied a few of JellySquid's Phosphor mod optimizations such as - ensuring we don't notify neighbor chunks when neighbor chunk doesn't need to be notified - reduce hasLight checks in initializing light, and prob some more, they are tagged JellySquid where phosphor influence was used. 3) Optimize hot path accesses to getting updating chunk to have less branching 4) Optimize getBlock accesses to have less branching, and less unpacking 5) Have a separate urgent bucket for chunk light tasks. These tasks will always cut in line over non blocking light tasks. 6) Retain chunk priority while light tasks are enqueued. So if a task comes in at high priority but the queue is full of tasks already at a lower priority, before the task was simply added to the end. Now it can cut in line to the front. this applies for both urgent and non urgent tasks. 7) Buffer non urgent tasks even if queueUpdate is called multiple times to improve efficiency. 8) Fix NPE risk that crashes server in getting nibble data Fixes #3489 Fixes #3363
2020-06-05 07:25:11 +02:00
index 4eb7c1a9b5afced4be79a263e6a918f39c4b51be..f6df85c6bf27bfa7a16967259a6016c9473201a5 100644
Optimise Chunk#getFluid (#2860) Removing the try catch and generally reducing ops should make it faster on its own, however removing the try catch makes it easier to inline due to code size
2020-03-18 13:21:35 +01:00
--- a/src/main/java/net/minecraft/server/ChunkSection.java
+++ b/src/main/java/net/minecraft/server/ChunkSection.java
Anti Xray cleanup Undo the accidental renaming of a method in 0aad8bf Aikar wanted to rename DataPalette#getDataBits(T object) to getOrCreateIdFor in 0aad8bf but he also accidentally renamed ChunkPacketInfo#getDataBitsIndex(int chunkSectionIndex) to getOrCreateIdForIndex. Remove chunk-edge-mode and chunk loading entirely from Anti-Xray The chunk-edge-mode is broken since several versions. Loading chunk neighbors for chunk edge obfuscation isn't needed anymore. Unlike in previous versions, these are under normal circumstances already loaded at the time we need them (plugins for example can bypass this). Use the modified methods and constructors everywhere Anti-Xray provides support for the default nms methods and constructors, which where modified by Anti-Xray to avoid breaking stuff (plugins) which somehow uses these methods. However, the modified versions of those methods and constructors should be used where possible.
2020-05-06 10:35:20 +02:00
@@ -37,7 +37,7 @@ public class ChunkSection {
Optimise Chunk#getFluid (#2860) Removing the try catch and generally reducing ops should make it faster on its own, however removing the try catch makes it easier to inline due to code size
2020-03-18 13:21:35 +01:00
}
public Fluid b(int i, int j, int k) {
- return ((IBlockData) this.blockIds.a(i, j, k)).getFluid();
+ return ((IBlockData) this.blockIds.a(i, j, k)).getFluid(); // Paper - diff on change - we expect this to be effectively just getType(x, y, z).getFluid(). If this changes we need to check other patches that use IBlockData#getFluid.
}
public void a() {
In neuem Issue referenzieren Permalink kopieren