Repo-Mirror/SparklyPaperMC
9
0
Fork 0
mirror of https://github.com/SparklyPower/SparklyPaper.git synced 2025-12-19 15:09:27 +00:00
Code Issues Releases Activity

Remove some "dubious" patches

Browse Source 
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
This commit is contained in:
MrPowerGamerBR
2023-11-24 02:48:58 -03:00
parent e509994f65
commit d17719e4e3
7 changed files with 11 additions and 86 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@@ -53,9 +53,6 @@ SparklyPaper's config file is `sparklypaper.yml`, the file is, by default, place
* The quintessential patch that other performance forks also have for... some reason??? I thought that this optimization was too funny to not do it in SparklyPaper.
* Caches when Bat's spooky season starts and ends, and when Skeleton and Zombies halloween starts and ends. The epoch is updated every 90 days. If your server is running for 90+ days straight without restarts, congratulations!
* Avoids unnecessary date checks, even tho that this shouldn't really improve performance that much... unless you have a lot of bats/zombies/skeletons spawning.
* Cache tracking range type enum ordinal
* Yes, I was shocked, flabbergasted even, when I found out that `Enum.ordinal()` was lagging when calling `Entity.getPlayersInTrackRange()`.
* 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" (in quotes, because it is actually accessing `int ordinal`) from enum to ordinal every time.
* Cache coordinate key used for nearby players when ticking chunks
* 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.
@@ -64,7 +61,6 @@ SparklyPaper's config file is `sparklypaper.yml`, the file is, by default, place
* The `canSee(...)` checks is in a hot path (`ChunkMap#updatePlayers()`), 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 fastutil's `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 hot path, we need all optimizations that we can get!).
* Cache last `shouldTickBlocksAt` result when ticking block entities
* The `shouldTickBlocksAt` call is expensive, it requires pulling chunk holder info from an map for each block entity (even if the block entities are on the same chunk!) every single time
* So here's a quick and dirty optimization: We cache the last `shouldTickBlocksAt` result and, if the last chunk position is the same as our cached value, we use the last cached `shouldTickBlocksAt` result!