Archiviert
13
0
Dieses Repository wurde am 2024-12-25 archiviert. Du kannst Dateien ansehen und es klonen, aber nicht pushen oder Issues/Pull-Requests öffnen.
Paper-Old/patches/server/0216-Improve-BlockPosition-inlining.patch
Jake Potrebic 526795bacd
Update patches to handle vineflower decompiler (#10406)
* Update patches to handle vineflower decompiler

* update patches again to handle inlined simple lambdas

* update vf again and re-apply/rebuild patches

* update patches after removal of verify-merges flag

* fix compile issue

* remove maven local

* fix some issues

* address more issues

* fix collision patch

* use paperweight release

* more fixes

* update fineflower and fix patches again

* add missing comment descriptor

---------

Co-authored-by: Jason Penilla <11360596+jpenilla@users.noreply.github.com>
2024-04-12 12:14:06 -07:00

61 Zeilen
2.6 KiB
Diff

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Techcable <Techcable@outlook.com>
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 64acf7d83d3419af603ad43172c35ed321a2d1c4..afb1e5ff7b1b6b42f81eaa7888a1ec3ded804ccb 100644
--- a/src/main/java/net/minecraft/core/Vec3i.java
+++ b/src/main/java/net/minecraft/core/Vec3i.java
@@ -37,12 +37,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();
}
@@ -55,15 +55,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;
}