OpenSource/PaperMC
OpenSource/PaperMC
1
0
Fork 0
mirror of https://github.com/PaperMC/Paper.git synced 2024-12-29 15:49:00 +01:00
Code Issues Projects Releases Packages Wiki Activity
PaperMC/Spigot-Server-Patches/Optimize-isValidLocation-getType-and-getBlockData-fo.patch

207 lines
9.9 KiB
Diff
Raw Normal View History

Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Aikar <aikar@aikar.co>
Date: Thu, 3 Mar 2016 02:07:55 -0600
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
Subject: [PATCH] Optimize isValidLocation, getType and getBlockData for
inlining
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
Hot methods, so reduce # of instructions for the method.
Move is valid location test to the BlockPosition class so that it can access local variables.
Replace all calls to the new place to the unnecessary forward.
Optimize getType and getBlockData to manually inline and optimize the calls
diff --git a/src/main/java/net/minecraft/server/BaseBlockPosition.java b/src/main/java/net/minecraft/server/BaseBlockPosition.java
Rebuild all patches using the new rebuild pattern
2020-05-06 11:48:49 +02:00
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
--- a/src/main/java/net/minecraft/server/BaseBlockPosition.java
+++ b/src/main/java/net/minecraft/server/BaseBlockPosition.java
@@ -0,0 +0,0 @@ public class BaseBlockPosition implements Comparable<BaseBlockPosition> {
Clean up a lot of obfuscation helpers and impls This fixes a bug with obfuscation helpers for attack cooldown But every other change should stay the same. Cleaning up a lot of helpers that pointed to already unobfuscated items. Also adds final to many of the obfhelpers to assist with inlining. This is pretty much a patch maintenance
2020-08-02 07:39:36 +02:00
private int b;public final void setY(final int y) { this.b = y; } // Paper - OBFHELPER
private int e;public final void setZ(final int z) { this.e = z; } // Paper - OBFHELPER
more progress
2020-06-25 13:00:35 +02:00
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
+ // Paper start
+ public boolean isValidLocation() {
more progress
2020-06-25 13:00:35 +02:00
+ return getX() >= -30000000 && getZ() >= -30000000 && getX() < 30000000 && getZ() < 30000000 && getY() >= 0 && getY() < 256;
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
+ }
+ public boolean isInvalidYLocation() {
+ return b < 0 || b >= 256;
+ }
+ // Paper end
more progress
2020-06-25 13:00:35 +02:00
+
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
public BaseBlockPosition(int i, int j, int k) {
this.a = i;
more progress
2020-06-25 13:00:35 +02:00
this.b = j;
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
diff --git a/src/main/java/net/minecraft/server/Chunk.java b/src/main/java/net/minecraft/server/Chunk.java
Rebuild all patches using the new rebuild pattern
2020-05-06 11:48:49 +02:00
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
--- a/src/main/java/net/minecraft/server/Chunk.java
+++ b/src/main/java/net/minecraft/server/Chunk.java
NOT FINISHED!!! Current Progress on 1.13-pre7 update This work is 100% unfinished. I am pushing it up so that we as a team can work on this update. Do not try to use this branch. You will fail.
2018-07-15 03:53:17 +02:00
@@ -0,0 +0,0 @@ public class Chunk implements IChunkAccess {
More 1.14 updates (#1995)
2019-04-27 05:05:36 +02:00
return this.sections;
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
}
More 1.14 updates (#1995)
2019-04-27 05:05:36 +02:00
- @Override
MC 1.14.1
2019-05-14 04:20:58 +02:00
+ // Paper start - Optimize getBlockData to reduce instructions
+ public final IBlockData getBlockData(BlockPosition pos) { return getBlockData(pos.getX(), pos.getY(), pos.getZ()); } // Paper
public IBlockData getType(BlockPosition blockposition) {
More 1.14 updates (#1995)
2019-04-27 05:05:36 +02:00
- int i = blockposition.getX();
- int j = blockposition.getY();
- int k = blockposition.getZ();
+ return this.getBlockData(blockposition.getX(), blockposition.getY(), blockposition.getZ());
+ }
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
+
+ public IBlockData getType(final int x, final int y, final int z) {
+ return getBlockData(x, y, z);
+ }
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
+ public final IBlockData getBlockData(final int x, final int y, final int z) {
+ // Method body / logic copied from below
+ final int i = y >> 4;
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
+ if (y < 0 || i >= this.sections.length || this.sections[i] == null || this.sections[i].nonEmptyBlockCount == 0) {
+ return Blocks.AIR.getBlockData();
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
+ }
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
+ // Inlined ChunkSection.getType() and DataPaletteBlock.a(int,int,int)
+ return this.sections[i].blockIds.a((y & 15) << 8 | (z & 15) << 4 | x & 15);
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
+ }
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
NOT FINISHED!!! Current Progress on 1.13-pre7 update This work is 100% unfinished. I am pushing it up so that we as a team can work on this update. Do not try to use this branch. You will fail.
2018-07-15 03:53:17 +02:00
+ public IBlockData getBlockData_unused(int i, int j, int k) {
+ // Paper end
more progress
2020-06-25 13:00:35 +02:00
if (this.world.isDebugWorld()) {
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
IBlockData iblockdata = null;
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
diff --git a/src/main/java/net/minecraft/server/ChunkEmpty.java b/src/main/java/net/minecraft/server/ChunkEmpty.java
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
--- a/src/main/java/net/minecraft/server/ChunkEmpty.java
+++ b/src/main/java/net/minecraft/server/ChunkEmpty.java
@@ -0,0 +0,0 @@ import javax.annotation.Nullable;
public class ChunkEmpty extends Chunk {
- private static final BiomeBase[] b = (BiomeBase[]) SystemUtils.a((Object) (new BiomeBase[BiomeStorage.a]), (abiomebase) -> {
1.16.2 Release (#4123) PaperMC believes that 1.16.2 is now ready for general release as we fixed the main issue plagueing the 1.16.x release, the MapLike data conversion issues. Until now, it was not safe for a server to convert a world to 1.16.2 without data conversion issues around villages and potentially other things. If you did, those MapLike errors meant something went wrong. This is now resolved. Big thanks to all those that helped, notably @BillyGalbreath and @Proximyst who did large parts of the update process with me. Please as always, backup your worlds and test before updating to 1.16.2! If you update to 1.16.2, there is no going back to an older build than this. --------------------------------- Co-authored-by: William Blake Galbreath <Blake.Galbreath@GMail.com> Co-authored-by: Mariell Hoversholm <proximyst@proximyst.com> Co-authored-by: krolik-exe <69214078+krolik-exe@users.noreply.github.com> Co-authored-by: BillyGalbreath <BillyGalbreath@users.noreply.github.com> Co-authored-by: stonar96 <minecraft.stonar96@gmail.com> Co-authored-by: Shane Freeder <theboyetronic@gmail.com> Co-authored-by: Jason Penilla <11360596+jpenilla@users.noreply.github.com> Co-authored-by: Riley Park <rileysebastianpark@gmail.com> Co-authored-by: Aurora <21148213+aurorasmiles@users.noreply.github.com> Co-authored-by: Nassim Jahnke <nassim@njahnke.dev> Co-authored-by: commandblockguy <commandblockguy1@gmail.com> Co-authored-by: DigitalRegent <misterwener@gmail.com> Co-authored-by: ishland <ishlandmc@yeah.net>
2020-08-25 04:22:08 +02:00
+ private static final BiomeBase[] b = SystemUtils.a((new BiomeBase[BiomeStorage.a]), (abiomebase) -> { // Paper - decompile error
Arrays.fill(abiomebase, BiomeRegistry.a);
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
});
@@ -0,0 +0,0 @@ public class ChunkEmpty extends Chunk {
1.16.2 Release (#4123) PaperMC believes that 1.16.2 is now ready for general release as we fixed the main issue plagueing the 1.16.x release, the MapLike data conversion issues. Until now, it was not safe for a server to convert a world to 1.16.2 without data conversion issues around villages and potentially other things. If you did, those MapLike errors meant something went wrong. This is now resolved. Big thanks to all those that helped, notably @BillyGalbreath and @Proximyst who did large parts of the update process with me. Please as always, backup your worlds and test before updating to 1.16.2! If you update to 1.16.2, there is no going back to an older build than this. --------------------------------- Co-authored-by: William Blake Galbreath <Blake.Galbreath@GMail.com> Co-authored-by: Mariell Hoversholm <proximyst@proximyst.com> Co-authored-by: krolik-exe <69214078+krolik-exe@users.noreply.github.com> Co-authored-by: BillyGalbreath <BillyGalbreath@users.noreply.github.com> Co-authored-by: stonar96 <minecraft.stonar96@gmail.com> Co-authored-by: Shane Freeder <theboyetronic@gmail.com> Co-authored-by: Jason Penilla <11360596+jpenilla@users.noreply.github.com> Co-authored-by: Riley Park <rileysebastianpark@gmail.com> Co-authored-by: Aurora <21148213+aurorasmiles@users.noreply.github.com> Co-authored-by: Nassim Jahnke <nassim@njahnke.dev> Co-authored-by: commandblockguy <commandblockguy1@gmail.com> Co-authored-by: DigitalRegent <misterwener@gmail.com> Co-authored-by: ishland <ishlandmc@yeah.net>
2020-08-25 04:22:08 +02:00
super(world, chunkcoordintpair, new BiomeStorage(world.r().b(IRegistry.ay), ChunkEmpty.b));
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
}
+ // Paper start
+ @Override public IBlockData getType(int x, int y, int z) {
+ return Blocks.VOID_AIR.getBlockData();
+ }
+ // Paper end
@Override
public IBlockData getType(BlockPosition blockposition) {
return Blocks.VOID_AIR.getBlockData();
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
diff --git a/src/main/java/net/minecraft/server/ChunkSection.java b/src/main/java/net/minecraft/server/ChunkSection.java
Rebuild all patches using the new rebuild pattern
2020-05-06 11:48:49 +02:00
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
--- a/src/main/java/net/minecraft/server/ChunkSection.java
+++ b/src/main/java/net/minecraft/server/ChunkSection.java
@@ -0,0 +0,0 @@ public class ChunkSection {
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
public static final DataPalette<IBlockData> GLOBAL_PALETTE = new DataPaletteGlobal<>(Block.REGISTRY_ID, Blocks.AIR.getBlockData());
private final int yPos;
- private short nonEmptyBlockCount;
+ short nonEmptyBlockCount; // Paper - package-private
More 1.14 updates (#1995)
2019-04-27 05:05:36 +02:00
private short tickingBlockCount;
private short e;
NOT FINISHED!!! Current Progress on 1.13-pre7 update This work is 100% unfinished. I am pushing it up so that we as a team can work on this update. Do not try to use this branch. You will fail.
2018-07-15 03:53:17 +02:00
- private final DataPaletteBlock<IBlockData> blockIds;
1.16.2 Release (#4123) PaperMC believes that 1.16.2 is now ready for general release as we fixed the main issue plagueing the 1.16.x release, the MapLike data conversion issues. Until now, it was not safe for a server to convert a world to 1.16.2 without data conversion issues around villages and potentially other things. If you did, those MapLike errors meant something went wrong. This is now resolved. Big thanks to all those that helped, notably @BillyGalbreath and @Proximyst who did large parts of the update process with me. Please as always, backup your worlds and test before updating to 1.16.2! If you update to 1.16.2, there is no going back to an older build than this. --------------------------------- Co-authored-by: William Blake Galbreath <Blake.Galbreath@GMail.com> Co-authored-by: Mariell Hoversholm <proximyst@proximyst.com> Co-authored-by: krolik-exe <69214078+krolik-exe@users.noreply.github.com> Co-authored-by: BillyGalbreath <BillyGalbreath@users.noreply.github.com> Co-authored-by: stonar96 <minecraft.stonar96@gmail.com> Co-authored-by: Shane Freeder <theboyetronic@gmail.com> Co-authored-by: Jason Penilla <11360596+jpenilla@users.noreply.github.com> Co-authored-by: Riley Park <rileysebastianpark@gmail.com> Co-authored-by: Aurora <21148213+aurorasmiles@users.noreply.github.com> Co-authored-by: Nassim Jahnke <nassim@njahnke.dev> Co-authored-by: commandblockguy <commandblockguy1@gmail.com> Co-authored-by: DigitalRegent <misterwener@gmail.com> Co-authored-by: ishland <ishlandmc@yeah.net>
2020-08-25 04:22:08 +02:00
+ final DataPaletteBlock<IBlockData> blockIds; // Paper - package-private
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
More 1.14 updates (#1995)
2019-04-27 05:05:36 +02:00
public ChunkSection(int i) {
this(i, (short) 0, (short) 0, (short) 0);
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
@@ -0,0 +0,0 @@ public class ChunkSection {
more progress
2020-06-25 13:00:35 +02:00
this.blockIds = new DataPaletteBlock<>(ChunkSection.GLOBAL_PALETTE, Block.REGISTRY_ID, GameProfileSerializer::c, GameProfileSerializer::a, Blocks.AIR.getBlockData());
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
}
- public IBlockData getType(int i, int j, int k) {
- return (IBlockData) this.blockIds.a(i, j, k);
+ public final IBlockData getType(int i, int j, int k) { // Paper
+ return this.blockIds.a(j << 8 | k << 4 | i); // Paper - inline
}
public Fluid b(int i, int j, int k) {
diff --git a/src/main/java/net/minecraft/server/DataPaletteBlock.java b/src/main/java/net/minecraft/server/DataPaletteBlock.java
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
--- a/src/main/java/net/minecraft/server/DataPaletteBlock.java
+++ b/src/main/java/net/minecraft/server/DataPaletteBlock.java
@@ -0,0 +0,0 @@ public class DataPaletteBlock<T> implements DataPaletteExpandable<T> {
}
public T a(int i, int j, int k) {
- return this.a(b(i, j, k));
+ return this.a(j << 8 | k << 4 | i); // Paper - inline
}
protected T a(int i) {
diff --git a/src/main/java/net/minecraft/server/IChunkAccess.java b/src/main/java/net/minecraft/server/IChunkAccess.java
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
--- a/src/main/java/net/minecraft/server/IChunkAccess.java
+++ b/src/main/java/net/minecraft/server/IChunkAccess.java
@@ -0,0 +0,0 @@ import org.apache.logging.log4j.LogManager;
public interface IChunkAccess extends IBlockAccess, IStructureAccess {
+ IBlockData getType(final int x, final int y, final int z); // Paper
@Nullable
IBlockData setType(BlockPosition blockposition, IBlockData iblockdata, boolean flag);
diff --git a/src/main/java/net/minecraft/server/ProtoChunk.java b/src/main/java/net/minecraft/server/ProtoChunk.java
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
--- a/src/main/java/net/minecraft/server/ProtoChunk.java
+++ b/src/main/java/net/minecraft/server/ProtoChunk.java
@@ -0,0 +0,0 @@ public class ProtoChunk implements IChunkAccess {
@Override
public IBlockData getType(BlockPosition blockposition) {
- int i = blockposition.getY();
-
- if (World.b(i)) {
+ return getType(blockposition.getX(), blockposition.getY(), blockposition.getZ());
+ }
+ // Paper start
+ public IBlockData getType(final int x, final int y, final int z) {
+ if (y < 0 || y >= 256) {
return Blocks.VOID_AIR.getBlockData();
} else {
- ChunkSection chunksection = this.getSections()[i >> 4];
-
- return ChunkSection.a(chunksection) ? Blocks.AIR.getBlockData() : chunksection.getType(blockposition.getX() & 15, i & 15, blockposition.getZ() & 15);
+ ChunkSection chunksection = this.getSections()[y >> 4];
+ return chunksection == Chunk.EMPTY_CHUNK_SECTION || chunksection.c() ? Blocks.AIR.getBlockData() : chunksection.getType(x & 15, y & 15, z & 15);
}
}
+ // Paper end
@Override
public Fluid getFluid(BlockPosition blockposition) {
diff --git a/src/main/java/net/minecraft/server/ProtoChunkExtension.java b/src/main/java/net/minecraft/server/ProtoChunkExtension.java
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
--- a/src/main/java/net/minecraft/server/ProtoChunkExtension.java
+++ b/src/main/java/net/minecraft/server/ProtoChunkExtension.java
@@ -0,0 +0,0 @@ public class ProtoChunkExtension extends ProtoChunk {
public IBlockData getType(BlockPosition blockposition) {
return this.a.getType(blockposition);
}
+ // Paper start
+ public final IBlockData getType(final int x, final int y, final int z) {
+ return this.a.getBlockData(x, y, z);
+ }
+ // Paper end
@Override
public Fluid getFluid(BlockPosition blockposition) {
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
diff --git a/src/main/java/net/minecraft/server/World.java b/src/main/java/net/minecraft/server/World.java
Rebuild all patches using the new rebuild pattern
2020-05-06 11:48:49 +02:00
index 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
--- a/src/main/java/net/minecraft/server/World.java
+++ b/src/main/java/net/minecraft/server/World.java
More progress
2019-12-11 03:43:21 +01:00
@@ -0,0 +0,0 @@ public abstract class World implements GeneratorAccess, AutoCloseable {
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
}
NOT FINISHED!!! Current Progress on 1.13-pre7 update This work is 100% unfinished. I am pushing it up so that we as a team can work on this update. Do not try to use this branch. You will fail.
2018-07-15 03:53:17 +02:00
public static boolean isValidLocation(BlockPosition blockposition) {
1.16.2 Release (#4123) PaperMC believes that 1.16.2 is now ready for general release as we fixed the main issue plagueing the 1.16.x release, the MapLike data conversion issues. Until now, it was not safe for a server to convert a world to 1.16.2 without data conversion issues around villages and potentially other things. If you did, those MapLike errors meant something went wrong. This is now resolved. Big thanks to all those that helped, notably @BillyGalbreath and @Proximyst who did large parts of the update process with me. Please as always, backup your worlds and test before updating to 1.16.2! If you update to 1.16.2, there is no going back to an older build than this. --------------------------------- Co-authored-by: William Blake Galbreath <Blake.Galbreath@GMail.com> Co-authored-by: Mariell Hoversholm <proximyst@proximyst.com> Co-authored-by: krolik-exe <69214078+krolik-exe@users.noreply.github.com> Co-authored-by: BillyGalbreath <BillyGalbreath@users.noreply.github.com> Co-authored-by: stonar96 <minecraft.stonar96@gmail.com> Co-authored-by: Shane Freeder <theboyetronic@gmail.com> Co-authored-by: Jason Penilla <11360596+jpenilla@users.noreply.github.com> Co-authored-by: Riley Park <rileysebastianpark@gmail.com> Co-authored-by: Aurora <21148213+aurorasmiles@users.noreply.github.com> Co-authored-by: Nassim Jahnke <nassim@njahnke.dev> Co-authored-by: commandblockguy <commandblockguy1@gmail.com> Co-authored-by: DigitalRegent <misterwener@gmail.com> Co-authored-by: ishland <ishlandmc@yeah.net>
2020-08-25 04:22:08 +02:00
- return !isOutsideWorld(blockposition) && D(blockposition);
+ return blockposition.isValidLocation(); // Paper - use better/optimized check
Optimize isInvalidYLocation, getType and getBlockData Some pretty micro optimizations, but this is the hottest method in the server.... This will drastically reduce number of operations to perform getType the 2 previous patches was squashed into 1
2016-06-23 04:43:02 +02:00
}
1.16.2 Release (#4123) PaperMC believes that 1.16.2 is now ready for general release as we fixed the main issue plagueing the 1.16.x release, the MapLike data conversion issues. Until now, it was not safe for a server to convert a world to 1.16.2 without data conversion issues around villages and potentially other things. If you did, those MapLike errors meant something went wrong. This is now resolved. Big thanks to all those that helped, notably @BillyGalbreath and @Proximyst who did large parts of the update process with me. Please as always, backup your worlds and test before updating to 1.16.2! If you update to 1.16.2, there is no going back to an older build than this. --------------------------------- Co-authored-by: William Blake Galbreath <Blake.Galbreath@GMail.com> Co-authored-by: Mariell Hoversholm <proximyst@proximyst.com> Co-authored-by: krolik-exe <69214078+krolik-exe@users.noreply.github.com> Co-authored-by: BillyGalbreath <BillyGalbreath@users.noreply.github.com> Co-authored-by: stonar96 <minecraft.stonar96@gmail.com> Co-authored-by: Shane Freeder <theboyetronic@gmail.com> Co-authored-by: Jason Penilla <11360596+jpenilla@users.noreply.github.com> Co-authored-by: Riley Park <rileysebastianpark@gmail.com> Co-authored-by: Aurora <21148213+aurorasmiles@users.noreply.github.com> Co-authored-by: Nassim Jahnke <nassim@njahnke.dev> Co-authored-by: commandblockguy <commandblockguy1@gmail.com> Co-authored-by: DigitalRegent <misterwener@gmail.com> Co-authored-by: ishland <ishlandmc@yeah.net>
2020-08-25 04:22:08 +02:00
public static boolean l(BlockPosition blockposition) {
Reference in a new issue Copy permalink