aboutsummaryrefslogtreecommitdiffhomepage
path: root/patches/server/0215-Improve-BlockPosition-inlining.patch
diff options
context:
space:
mode:
authorSpottedleaf <[email protected]>2024-07-17 10:24:53 -0700
committerSpottedleaf <[email protected]>2024-07-17 10:28:32 -0700
commit00b949f1bbbf444e2b5e7b8de7c9b14fbd2133c6 (patch)
tree82639515bc5e9ae00c1e639e72137ed51e1ac688 /patches/server/0215-Improve-BlockPosition-inlining.patch
parent967f98aa81da851740aeb429778e46159fd188df (diff)
downloadPaper-00b949f1bbbf444e2b5e7b8de7c9b14fbd2133c6.tar.gz
Paper-00b949f1bbbf444e2b5e7b8de7c9b14fbd2133c6.zip
Remove Moonrise utils to MCUtils, remove duplicated/unused utils
Diffstat (limited to 'patches/server/0215-Improve-BlockPosition-inlining.patch')
-rw-r--r--patches/server/0215-Improve-BlockPosition-inlining.patch60
1 files changed, 60 insertions, 0 deletions
diff --git a/patches/server/0215-Improve-BlockPosition-inlining.patch b/patches/server/0215-Improve-BlockPosition-inlining.patch
new file mode 100644
index 0000000000..469c5f7390
--- /dev/null
+++ b/patches/server/0215-Improve-BlockPosition-inlining.patch
@@ -0,0 +1,60 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Techcable <[email protected]>
+Date: Wed, 30 Nov 2016 20:56:58 -0600
+Subject: [PATCH] Improve BlockPosition inlining
+
+Normally the JVM can inline virtual getters by having two sets of code, one is the 'optimized' code and the other is the 'deoptimized' code.
+If a single type is used 99% of the time, then its worth it to inline, and to revert to 'deoptimized' the 1% of the time we encounter other types.
+But if two types are encountered commonly, then the JVM can't inline them both, and the call overhead remains.
+
+This scenario also occurs with BlockPos and MutableBlockPos.
+The variables in BlockPos are final, so MutableBlockPos can't modify them.
+MutableBlockPos fixes this by adding custom mutable variables, and overriding the getters to access them.
+
+This approach with utility methods that operate on MutableBlockPos and BlockPos.
+Specific examples are BlockPosition.up(), and World.isValidLocation().
+It makes these simple methods much slower than they need to be.
+
+This should result in an across the board speedup in anything that accesses blocks or does logic with positions.
+
+This is based upon conclusions drawn from inspecting the assenmbly generated bythe JIT compiler on my microbenchmarks.
+They had 'callq' (invoke) instead of 'mov' (get from memory) instructions.
+
+diff --git a/src/main/java/net/minecraft/core/Vec3i.java b/src/main/java/net/minecraft/core/Vec3i.java
+index ea4660fe600db94e97a5dd335135f76dd5951468..df4c9b275752ad97a4efe9380ae0d511ee760695 100644
+--- a/src/main/java/net/minecraft/core/Vec3i.java
++++ b/src/main/java/net/minecraft/core/Vec3i.java
+@@ -35,12 +35,12 @@ public class Vec3i implements Comparable<Vec3i> {
+ }
+
+ @Override
+- public boolean equals(Object object) {
++ public final boolean equals(Object object) { // Paper - Perf: Final for inline
+ return this == object || object instanceof Vec3i vec3i && this.getX() == vec3i.getX() && this.getY() == vec3i.getY() && this.getZ() == vec3i.getZ();
+ }
+
+ @Override
+- public int hashCode() {
++ public final int hashCode() { // Paper - Perf: Final for inline
+ return (this.getY() + this.getZ() * 31) * 31 + this.getX();
+ }
+
+@@ -53,15 +53,15 @@ public class Vec3i implements Comparable<Vec3i> {
+ }
+ }
+
+- public int getX() {
++ public final int getX() { // Paper - Perf: Final for inline
+ return this.x;
+ }
+
+- public int getY() {
++ public final int getY() { // Paper - Perf: Final for inline
+ return this.y;
+ }
+
+- public int getZ() {
++ public final int getZ() { // Paper - Perf: Final for inline
+ return this.z;
+ }
+