Replace item frame patch

README.md

@@ -30,10 +30,11 @@ SparklyPaper's config file is `sparklypaper.yml`, the file is, by default, place
   * Instead of using Java's HashSet, we will use fastutil's `ObjectOpenHashSet`, which has better performance
   * While this seems stupid, awardStat was using around ~0.14% when adding to the `HashSet`, and that's not good
   * We also optimized the `getDirty` calls. I mean, the *only* `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.
-* Avoid unnecessary `ItemFrame#getItem()` calls
-  * When ticking an item frame, on each tick, it checks if the item on the item frame is a map and, if it is, it adds the map to be carried by the entity player
-  * However, the `getItem()` call is a bit expensive, especially because this is only really used if the item in the item frame is a map
-  * We can avoid this call by checking if the `cachedMapId` is not null, if it is, then we get the item in the item frame, if not, then we ignore the `getItem()` call.
+* ~~Avoid unnecessary `ItemFrame#getItem()` calls
+  * ~~When ticking an item frame, on each tick, it checks if the item on the item frame is a map and, if it is, it adds the map to be carried by the entity player~~
+  * ~~However, the `getItem()` call is a bit expensive, especially because this is only really used if the item in the item frame is a map~~
+  * ~~We can avoid this call by checking if the `cachedMapId` is not null, if it is, then we get the item in the item frame, if not, then we ignore the `getItem()` call.~~
+  * Replaced by [Warriorrrr's "Rewrite framed map tracker ticking" patch (Paper #9605)](https://github.com/PaperMC/Paper/pull/9605)
 * Optimize `EntityScheduler`'s `executeTick`
   * On each tick, Paper runs `EntityScheduler`'s `executeTick` of each entity. This is a bit expensive, due to `ArrayDeque`'s `size()` call because it ain't a simple "get the current queue size" function, and due to the thread checks.
   * To avoid the hefty `ArrayDeque`'s `size()` call, we check if we *really* need to execute the `executeTick`, by checking if `currentlyExecuting` is not empty or if `oneTimeDelayed` is not empty. This brings `executeTick`'s CPU % from 2.46% down to 1.14% in a server with ~13k entities.