PaperMC/paper-server
Techcable 85be8cc620 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.
2016-11-30 20:56:58 -06:00
..
patches/sources Improve BlockPosition inlining 2016-11-30 20:56:58 -06:00
src Vex#get/setSummoner API 2018-07-04 15:30:22 -04:00
.gitignore Setup Gradle project 2020-12-10 20:54:19 -08:00
build.gradle.kts Expose server build information 2016-03-01 14:32:43 -06:00
LGPL.txt We're LGPL. 2011-01-02 10:58:11 +01:00
LICENCE.txt We're LGPL. 2011-01-02 10:58:11 +01:00