I made some amazing changes for the sake of performance of the library :>
[!CAUTION]
Might need a little bit of testing.
The most significant performance improvements include but are not limited to:
The removal of one of the heaviest events in minecraft: The PlayerMoveEvent.
EntityMoveEvent has not been removed because it would only cause more performance and flexibility issues
PlayerMoveEvent followHandler will be removed to be replaced by proper pathfinding AI (hence the UnstableAi branch).
PlayerMoveEvent was used to detect movement of a player and distances between the player and an InternalNpc
For most small servers this does not matter.
but since this PlayerMoveEvent ticks EVERY player, and one tick is only 50 milliseconds, it can burn those millis fast and produce overhead.
This is a problem because of the poor ticking design of minecraft that ruin the performance.
Instead, I replaced it with a ScheduledExecutorService that will asynchronously run the process of tracking old movements and then replacing them with new movement locations.
this functions very similarily to the old one, just a lot faster, better handled, asynchronous, less frequently called (but unnoticable)
And much more caches (in memory).
[!WARNING]
Listeners#stop method should definitely be called at JavaPlugin#onDisable so that the cached threads in the ScheduledExecutorService would shut down and unallocate allocated memory
The discontinue of using Location#distance which uses a very costly root function called "square root", and use Location#distanceSquared
This is not usually a problem and it's definitely okay to use Math#sqrt once in a while.
But when it runs in hot code, like EntityMoveEvent, (this varies, but PlayerVelocityEvent), and some other events in Listener.
It can lead to some overhead and cause the TPS to drop.
Instead we use Location#distanceSquared, one problem with using Location#distanceSquared is sometimes the numbers look
more confusing than when using Location#distance (48 * 48 equals around 2304), so I have introduced helper constants that help with identifying how many blocks is a number.
5 blocks is FIVE_BLOCKS, 0.25 is HALF_BLOCK (sqrt(0.5) = 0.25), 48 is FOURTY_BLOCKS
Now, There was just two issues when I looked at this code:
There was some really unnecessary nesting in that code, by being a natural never-nester, I made this code good myself (because I coded optimizations for this class so I'm gonna be just a little bit narcissist)
so unless it was necessary, I removed any nesting and replaced it with a "return" or "continue" that
would later be removed by the compiler anyways and nest the code for us.
There is a possibility that a player CAN leave the server while the plugin waits for them to do something;
like name an NPC, or wait for a message, or add args, etc.
There would be dead Player objects that just don't do anything and take up memory, and Player objects take LOTS of memory.
to fix this issue; there were 3 ways to fix this issue:
Convert Player into UUIDs since UUID take only 16 bits of ram (excluding the class initialization memory consumption itself) since it only contains 2 longs per instance.
Properly remove Players from Sets and Lists
Sleep eight hours in college without faili- I mean give the player loads of problems to deal with when rejoining.
Now the last option can be a config (just fail college) by just not removing the stuff on leave.
Fixing these issue can improve code quality and code maintainability + readability between others.
These were not made by an IDE (D:) but these were compile-time tested.
I made some amazing changes for the sake of performance of the library :>
The most significant performance improvements include but are not limited to:
The removal of one of the heaviest events in minecraft: The PlayerMoveEvent. EntityMoveEvent has not been removed because it would only cause more performance and flexibility issues PlayerMoveEvent followHandler will be removed to be replaced by proper pathfinding AI (hence the UnstableAi branch).
PlayerMoveEvent was used to detect movement of a player and distances between the player and an InternalNpc For most small servers this does not matter.
but since this PlayerMoveEvent ticks EVERY player, and one tick is only 50 milliseconds, it can burn those millis fast and produce overhead. This is a problem because of the poor ticking design of minecraft that ruin the performance.
Instead, I replaced it with a ScheduledExecutorService that will asynchronously run the process of tracking old movements and then replacing them with new movement locations. this functions very similarily to the old one, just a lot faster, better handled, asynchronous, less frequently called (but unnoticable) And much more caches (in memory).
The discontinue of using Location#distance which uses a very costly root function called "square root", and use Location#distanceSquared This is not usually a problem and it's definitely okay to use Math#sqrt once in a while.
But when it runs in hot code, like EntityMoveEvent, (this varies, but PlayerVelocityEvent), and some other events in Listener. It can lead to some overhead and cause the TPS to drop.
Instead we use Location#distanceSquared, one problem with using Location#distanceSquared is sometimes the numbers look more confusing than when using Location#distance (48 * 48 equals around 2304), so I have introduced helper constants that help with identifying how many blocks is a number.
5 blocks is FIVE_BLOCKS, 0.25 is HALF_BLOCK (sqrt(0.5) = 0.25), 48 is FOURTY_BLOCKS
Now, There was just two issues when I looked at this code:
There was some really unnecessary nesting in that code, by being a natural never-nester, I made this code good myself (because I coded optimizations for this class so I'm gonna be just a little bit narcissist) so unless it was necessary, I removed any nesting and replaced it with a "return" or "continue" that would later be removed by the compiler anyways and nest the code for us.
There is a possibility that a player CAN leave the server while the plugin waits for them to do something; like name an NPC, or wait for a message, or add args, etc. There would be dead Player objects that just don't do anything and take up memory, and Player objects take LOTS of memory.
to fix this issue; there were 3 ways to fix this issue:
Fixing these issue can improve code quality and code maintainability + readability between others.
These were not made by an IDE (D:) but these were compile-time tested.