Honestly, some of these changes felt like hopium "surely this will fix the lag issues", even tho in my mind these didn't make sense
Yeah, these methods do show up in the profiler, but does these *really* make sense? I don't think so, I think these are just useless patches that only attempt to hide the pain, instead of tackling the REAL issue that is causing these methods to show up in the profiler
Again, this is seems like a small optimization, but it is actually useful because we avoid doing calculations for each block entity, and if your server has a lot of them, it adds up
The "canSee" checks is in a hot path, invoked by each entity for each player on the server if they are in tracking range, so optimizing it is pretty nice
First, we change the original "HashMap" to fastutil's "Object2ObjectOpenHashMap", because the containsKey throughput is better
Then, we add a "isEmpty()" check before attempting to check if the map contains something
This seems stupid, but it does seem that it improves the performance a bit, and it makes sense, "containsKey(...)" does not attempt to check the map size before attempting to check if the map contains the key
We also create a "canSee" method tailored for "ChunkMap#updatePlayer()", a method without the equals check (the "updatePlayer()" already checks if the entity is the same entity) and we cache the "isVisibleByDefault()" result between runs (this also seems a bit overkill because "isVisibleByDefault()" is just a method that returns a boolean, but because this is a hotpath, we need all optimizations that we can get
There's literally only one getDirty call. Because the map was only retrieved once, we don't actually need to create a copy of the map just to iterate it, we can just access it directly and clear it manually after use.
The "getChunkKey(...)" call is a bit expensive, using 0.24% of CPU time with 19k chunks loaded
So instead of paying the price on each tick, we pay the price when the chunk is loaded
Which, if you think about it, is actually better, since we tick chunks more than we load chunks
Yes, I was shocked, flabbergasted even, when I found out that "Enum.ordinal()" was lagging here
But I guess it makes sense: It is a function that is called every tick for each entity, and it is a bit wasteful converting from enum to ordinal every time
The quintessential patch that other performance forks also have for... some reason
Caches when Bat's spooky season starts and ends, and when Skeleton and Zombies halloween starts and ends
Avoids unnecessary date checks, even tho that this shouldn't really improve performance that much... unless you have a lot of mobs being spawned
For each player on each tick, enter block triggers are invoked, and these create loot contexts that are promptly thrown away since the trigger doesn't pass the predicate
To avoid this, we now lazily create the LootContext if the criterion passes the predicate AND if any of the listener triggers require a loot context instance
