279
This commit is contained in:
		
					parent
					
						
							
								9120ce5d4b
							
						
					
				
			
			
				commit
				
					
						e07671b7df
					
				
			
		
					 86 changed files with 231 additions and 248 deletions
				
			
		
							
								
								
									
										60
									
								
								patches/server/Improve-BlockPosition-inlining.patch
									
										
									
									
									
										Normal file
									
								
							
							
						
						
									
										60
									
								
								patches/server/Improve-BlockPosition-inlining.patch
									
										
									
									
									
										Normal file
									
								
							|  | @ -0,0 +1,60 @@ | |||
| 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 0000000000000000000000000000000000000000..0000000000000000000000000000000000000000 100644
 | ||||
| --- a/src/main/java/net/minecraft/core/Vec3i.java
 | ||||
| +++ b/src/main/java/net/minecraft/core/Vec3i.java
 | ||||
| @@ -0,0 +0,0 @@ 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(); | ||||
|      } | ||||
|   | ||||
| @@ -0,0 +0,0 @@ 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; | ||||
|      } | ||||
|   | ||||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue
	
	 Jake Potrebic
				Jake Potrebic