MC-95535Multiple hopper performance issues
I run a decent sized Minecraft server that tries to not restrict players as much as possible.
My players love to build redstone contraptions, including item sorters and movers, resulting in LOTS of Hoppers, sometimes hitting 40,000+ Tile Entities, or 2000 Hoppers in a single area.
This has drastic impact to server performance causing every players experience to be degraded by loss of TPS.
After EXTENSIVE research using a profiler and studying the code, I've identified numerous issues with the hopper system.
- Hoppers by proper design, call the .update() method on an inventory when it has been modified in some way, to trigger physics and comparators.
However, many inventory manipulation methods also call .update()
This results in .update being called many times, which then triggers comparators and other physics events. This single handedly crushes servers with hoppers. - Unnecessary ItemStack cloning
The server calls itemstack.clone() on EVERY item stack it 'trys'. Take TileEntityHopper.a(IHopper) for example.
If an inventory of say 50 items in a chest is trying to be moved to a hopper, and that hopper only has 1 free slot and nothing matches the chests inventory, this method will result in every one of those item stacks being cloned every tick, only for it to fail to be moved and now an instance of the itemstack will be GC'd - Inefficient Item Suck In behavior
Hoppers will out-number ItemStacks in any matured world, and has potential to be loaded longer term than an item stack. It does not make sense that hoppers perform AABB lookups for Entities.
As of 1.13-1.15, this now also does 2 lookups per hopper due to the advanced hitbox. This needs to be a simple lookup again.
Also, no reason to suck in if there is a full solid occluding block above the hopper. - Usage of streams hurts performance due to overhead, complex call stacks. JVM does better at optimizing non stream code, and Java 8 is not receiving stream optimizations.
Solutions:
First I will reference my patch on how I quick patched in solutions, though not always perfect - note there are some non vanilla matters here but will lay out the vanilla relevant elements:
https://github.com/PaperMC/Paper/blob/10502558e92f478e7e1343193dd8ace8dbf8ac78/Spigot-Server-Patches/0414-Optimize-Hoppers.patch
- For cloning issue, I suggest using itemstack count manipulation like I am doing in my patch. This avoids calls to .update() from split stack methods which partially resolves issue #1 also. CraftBukkit made the cloning problem even worse, but Vanilla does pre clone too, so the concept is valid in Vanilla
- For the .update call, if switching off using the manipulation methods, some of the .update() calls are now handled, but in TileEntityHopper.c(IInventory, ItemStack, int, EnumDirection) method where the actual inventory manipulation takes place, iinventory.setItem() where itemstack1 is null can also trigger .update() on chests. adding some method to setWithoutUpdate instead on the interface is possibly the most ideal instead of my hack method.
- For Hopper Suck In, Instead, ItemStacks could instead look for hoppers to ping them to suck them in, which can do much more efficient Tile Entity BlockPosition lookups. But would still need an Entity AABB for the Minecarts, but the overall occurrence would drastically be reduced.
- Hoppers are able to engage the automatic loot filling on a chest. However no reason to run that check multiple times, just do it on first index only
- Hoppers in 1.13+ (or at least 1.15) are now sucking in twice, once for each part of the complex shape of a Hopper. Bowl level pixel perfect bounding boxes are unnecessary. Restore the single AABB lookup from 1.12
- Removal of all usages of Streams. hoppers are hot. Streams have overhead that added up quite a lot and also seems to hurt JVM optimizations. Since MC runs on java 8, which is not receiving performance improvements to Streams/JIT, this hurts. This includes isEmpty() in Lootable.
- Skip item suck in behavior if the block above the hopper is full cuboid solid at all. Items collide with blocks and this scenario should never naturally occur where an item phases into a solid block and then gets sucked in. ( https://github.com/PaperMC/Paper/blob/10502558e92f478e7e1343193dd8ace8dbf8ac78/Spigot-Server-Patches/0414-Optimize-Hoppers.patch#L453 )
- Since .getItem() on some inventories (Lootable types) have additional overhead, keep result from first call and pass it to dependent methods
NormalCreated Issue:
Multiple Hopper Performance Issues
I run a decent sized Minecraft server that tries to not restrict players as much as possible.
My players love to build redstone contraptions, including item sorters and movers, resulting in LOTS of Hoppers, sometimes hitting 40,000+ Tile Entities, or 2000 Hoppers in a single area.
This has drastic impact to server performance causing every players experience to be degraded by loss of TPS.
After EXTENSIVE research using a profiler and studying the code, I've identified numerous issues with the hopper system.
- Hoppers by proper design, call the .update() method on an inventory when it has been modified in some way, to trigger physics and comparators.
However, many inventory manipulation methods also call .update()
This results in .update being called many times, which then triggers comparators and other physics events. This single handedly crushes servers with hoppers.- Unnecessary ItemStack cloning
The server calls itemstack.clone() on EVERY item stack it 'trys'. Take TileEntityHopper.a(IHopper) for example.
If an inventory of say 50 items in a chest is trying to be moved to a hopper, and that hopper only has 1 free slot and nothing matches the chests inventory, this method will result in every one of those item stacks being cloned every tick, only for it to fail to be moved and now an instance of the itemstack will be GC'd- Inefficient Item Suck In behavior
Hoppers will out-number ItemStacks in any matured world, and has potential to be loaded longer term than an item stack. It does not make sense that hoppers perform AABB lookups for Entities.Solutions:
First I will reference my patch on how I quick patched in solutions, though not always perfect:
https://bitbucket.org/starlis/empirecraft/src/05f5bb0a3bb9576430e97ea6ef32a9785e8e6f6f/patches/craftbukkit/0097-Fix-Minecraft-Fix-Hoppers.patch?fileviewer=file-view-default
- For cloning issue, I suggest using itemstack count manipulation like I am doing in my patch. This avoids calls to .update() from split stack methods which partially resolves issue #1 also
- For the .update call, if switching off using the manipulation methods, some of the .update() calls are now handled, but in TileEntityHopper.c(IInventory, ItemStack, int, EnumDirection) method where the actual inventory manipulation takes place, iinventory.setItem() where itemstack1 is null can also trigger .update() on chests. adding some method to setWithoutUpdate instead on the interface is possibly the most ideal instead of my hack method.
- For Hopper Suck In, Instead, ItemStacks should instead look for hoppers to ping them to suck them in, which can do much more efficient Tile Entity BlockPosition lookups. But would still need an Entity AABB for the Minecarts, but the overall occurrence would drastically be reduced.
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
I run a decent sized Minecraft server that tries to not restrict players as much as possible.
My players love to build redstone contraptions, including item sorters and movers, resulting in LOTS of Hoppers, sometimes hitting 40,000+ Tile Entities, or 2000 Hoppers in a single area.
This has drastic impact to server performance causing every players experience to be degraded by loss of TPS.
After EXTENSIVE research using a profiler and studying the code, I've identified numerous issues with the hopper system.
- Hoppers by proper design, call the .update() method on an inventory when it has been modified in some way, to trigger physics and comparators.
However, many inventory manipulation methods also call .update()
This results in .update being called many times, which then triggers comparators and other physics events. This single handedly crushes servers with hoppers.
There is also a literal duplicate .update() call in the method that calls the .update() after flag = true. Only 1 is needed.- Unnecessary ItemStack cloning
The server calls itemstack.clone() on EVERY item stack it 'trys'. Take TileEntityHopper.a(IHopper) for example.
If an inventory of say 50 items in a chest is trying to be moved to a hopper, and that hopper only has 1 free slot and nothing matches the chests inventory, this method will result in every one of those item stacks being cloned every tick, only for it to fail to be moved and now an instance of the itemstack will be GC'd- Inefficient Item Suck In behavior
Hoppers will out-number ItemStacks in any matured world, and has potential to be loaded longer term than an item stack. It does not make sense that hoppers perform AABB lookups for Entities.Solutions:
First I will reference my patch on how I quick patched in solutions, though not always perfect:
https://bitbucket.org/starlis/empirecraft/src/05f5bb0a3bb9576430e97ea6ef32a9785e8e6f6f/patches/craftbukkit/0097-Fix-Minecraft-Fix-Hoppers.patch?fileviewer=file-view-default
- For cloning issue, I suggest using itemstack count manipulation like I am doing in my patch. This avoids calls to .update() from split stack methods which partially resolves issue #1 also
- For the .update call, if switching off using the manipulation methods, some of the .update() calls are now handled, but in TileEntityHopper.c(IInventory, ItemStack, int, EnumDirection) method where the actual inventory manipulation takes place, iinventory.setItem() where itemstack1 is null can also trigger .update() on chests. adding some method to setWithoutUpdate instead on the interface is possibly the most ideal instead of my hack method.
- For Hopper Suck In, Instead, ItemStacks should instead look for hoppers to ping them to suck them in, which can do much more efficient Tile Entity BlockPosition lookups. But would still need an Entity AABB for the Minecarts, but the overall occurrence would drastically be reduced.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w43a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time. If you are the owner/reporter of this ticket, you can modify the affected version(s) yourself.
MultipleHopperPerformanceIssuesMultiple hopper performance issues
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
Is this still an issue in 1.13.2?
Can someone please check, if this still applies to 1.15.2 or the latest 1.16 development snapshot (currently that is 20w07a)?
I run a decent sized Minecraft server that tries to not restrict players as much as possible.
My players love to build redstone contraptions, including item sorters and movers, resulting in LOTS of Hoppers, sometimes hitting 40,000+ Tile Entities, or 2000 Hoppers in a single area.
This has drastic impact to server performance causing every players experience to be degraded by loss of TPS.
After EXTENSIVE research using a profiler and studying the code, I've identified numerous issues with the hopper system.
- Hoppers by proper design, call the .update() method on an inventory when it has been modified in some way, to trigger physics and comparators.
However, many inventory manipulation methods also call .update()
This results in .update being called many times, which then triggers comparators and other physics events. This single handedly crushes servers with hoppers.
There is also a literal duplicate .update() call in the method that calls the .update() after flag = true. Only 1 is needed.- Unnecessary ItemStack cloning
The server calls itemstack.clone() on EVERY item stack it 'trys'. Take TileEntityHopper.a(IHopper) for example.
If an inventory of say 50 items in a chest is trying to be moved to a hopper, and that hopper only has 1 free slot and nothing matches the chests inventory, this method will result in every one of those item stacks being cloned every tick, only for it to fail to be moved and now an instance of the itemstack will be GC'd- Inefficient Item Suck In behavior
Hoppers will out-number ItemStacks in any matured world, and has potential to be loaded longer term than an item stack. It does not make sense that hoppers perform AABB lookups for Entities.Solutions:
First I will reference my patch on how I quick patched in solutions, though not always perfect:
https://bitbucket.org/starlis/empirecraft/src/05f5bb0a3bb9576430e97ea6ef32a9785e8e6f6f/patches/craftbukkit/0097-Fix-Minecraft-Fix-Hoppers.patch?fileviewer=file-view-default
- For cloning issue, I suggest using itemstack count manipulation like I am doing in my patch. This avoids calls to .update() from split stack methods which partially resolves issue #1 also
- For the .update call, if switching off using the manipulation methods, some of the .update() calls are now handled, but in TileEntityHopper.c(IInventory, ItemStack, int, EnumDirection) method where the actual inventory manipulation takes place, iinventory.setItem() where itemstack1 is null can also trigger .update() on chests.
adding some method to setWithoutUpdate instead on the interface is possibly the most ideal instead of my hack method.For Hopper Suck In, Instead, ItemStacks should instead look for hoppers to ping them to suck them in, which can do much more efficient Tile Entity BlockPosition lookups. But would still need an Entity AABB for the Minecarts, but the overall occurrence would drastically be reduced.I run a decent sized Minecraft server that tries to not restrict players as much as possible.
My players love to build redstone contraptions, including item sorters and movers, resulting in LOTS of Hoppers, sometimes hitting 40,000+ Tile Entities, or 2000 Hoppers in a single area.
This has drastic impact to server performance causing every players experience to be degraded by loss of TPS.
After EXTENSIVE research using a profiler and studying the code, I've identified numerous issues with the hopper system.
- Hoppers by proper design, call the .update() method on an inventory when it has been modified in some way, to trigger physics and comparators.
However, many inventory manipulation methods also call .update()
This results in .update being called many times, which then triggers comparators and other physics events. This single handedly crushes servers with hoppers.
There is also a literal duplicate .update() call in the method that calls the .update() after flag = true. Only 1 is needed.- Unnecessary ItemStack cloning
The server calls itemstack.clone() on EVERY item stack it 'trys'. Take TileEntityHopper.a(IHopper) for example.
If an inventory of say 50 items in a chest is trying to be moved to a hopper, and that hopper only has 1 free slot and nothing matches the chests inventory, this method will result in every one of those item stacks being cloned every tick, only for it to fail to be moved and now an instance of the itemstack will be GC'd- Inefficient Item Suck In behavior
Hoppers will out-number ItemStacks in any matured world, and has potential to be loaded longer term than an item stack. It does not make sense that hoppers perform AABB lookups for Entities.
As of 1.13-1.15, this now also does 2 lookups per hopper due to the advanced hitbox. This needs to be a simple lookup again.
Also, no reason to suck in if there is a full solid occluding block above the hopper.- Usage of streams hurts performance due to overhead, complex call stacks. JVM does better at optimizing non stream code, and Java 8 is not receiving stream optimizations.
Solutions:
First I will reference my patch on how I quick patched in solutions, though not always perfect - note there are some non vanilla matters here but will lay out the vanilla relevant elements:
https://github.com/PaperMC/Paper/blob/10502558e92f478e7e1343193dd8ace8dbf8ac78/Spigot-Server-Patches/0414-Optimize-Hoppers.patch
- For cloning issue, I suggest using itemstack count manipulation like I am doing in my patch. This avoids calls to .update() from split stack methods which partially resolves issue #1 also. CraftBukkit made the cloning problem even worse, but Vanilla does pre clone too, so the concept is valid in Vanilla
- For the .update call, if switching off using the manipulation methods, some of the .update() calls are now handled, but in TileEntityHopper.c(IInventory, ItemStack, int, EnumDirection) method where the actual inventory manipulation takes place, iinventory.setItem() where itemstack1 is null can also trigger .update() on chests. adding some method to setWithoutUpdate instead on the interface is possibly the most ideal instead of my hack method.
- For Hopper Suck In, Instead, ItemStacks could instead look for hoppers to ping them to suck them in, which can do much more efficient Tile Entity BlockPosition lookups. But would still need an Entity AABB for the Minecarts, but the overall occurrence would drastically be reduced.
- Hoppers are able to engage the automatic loot filling on a chest. However no reason to run that check multiple times, just do it on first index only
- Hoppers in 1.13+ (or at least 1.15) are now sucking in twice, once for each part of the complex shape of a Hopper. Bowl level pixel perfect bounding boxes are unnecessary. Restore the single AABB lookup from 1.12
- Removal of all usages of Streams. hoppers are hot. Streams have overhead that added up quite a lot and also seems to hurt JVM optimizations. Since MC runs on java 8, which is not receiving performance improvements to Streams/JIT, this hurts. This includes isEmpty() in Lootable.
- Skip item suck in behavior if the block above the hopper is full cuboid solid at all. Items collide with blocks and this scenario should never naturally occur where an item phases into a solid block and then gets sucked in. ( https://github.com/PaperMC/Paper/blob/10502558e92f478e7e1343193dd8ace8dbf8ac78/Spigot-Server-Patches/0414-Optimize-Hoppers.patch#L453 )
- Since .getItem() on some inventories (Lootable types) have additional overhead, keep result from first call and pass it to dependent methods
I run a decent sized Minecraft server that tries to not restrict players as much as possible.
My players love to build redstone contraptions, including item sorters and movers, resulting in LOTS of Hoppers, sometimes hitting 40,000+ Tile Entities, or 2000 Hoppers in a single area.
This has drastic impact to server performance causing every players experience to be degraded by loss of TPS.
After EXTENSIVE research using a profiler and studying the code, I've identified numerous issues with the hopper system.
- Hoppers by proper design, call the .update() method on an inventory when it has been modified in some way, to trigger physics and comparators.
However, many inventory manipulation methods also call .update()
This results in .update being called many times, which then triggers comparators and other physics events. This single handedly crushes servers with hoppers.
There is also a literal duplicate .update() call in the method that calls the .update() after flag = true. Only 1 is needed.- Unnecessary ItemStack cloning
The server calls itemstack.clone() on EVERY item stack it 'trys'. Take TileEntityHopper.a(IHopper) for example.
If an inventory of say 50 items in a chest is trying to be moved to a hopper, and that hopper only has 1 free slot and nothing matches the chests inventory, this method will result in every one of those item stacks being cloned every tick, only for it to fail to be moved and now an instance of the itemstack will be GC'd- Inefficient Item Suck In behavior
Hoppers will out-number ItemStacks in any matured world, and has potential to be loaded longer term than an item stack. It does not make sense that hoppers perform AABB lookups for Entities.
As of 1.13-1.15, this now also does 2 lookups per hopper due to the advanced hitbox. This needs to be a simple lookup again.
Also, no reason to suck in if there is a full solid occluding block above the hopper.- Usage of streams hurts performance due to overhead, complex call stacks. JVM does better at optimizing non stream code, and Java 8 is not receiving stream optimizations.
Solutions:
First I will reference my patch on how I quick patched in solutions, though not always perfect - note there are some non vanilla matters here but will lay out the vanilla relevant elements:
https://github.com/PaperMC/Paper/blob/10502558e92f478e7e1343193dd8ace8dbf8ac78/Spigot-Server-Patches/0414-Optimize-Hoppers.patch
- For cloning issue, I suggest using itemstack count manipulation like I am doing in my patch. This avoids calls to .update() from split stack methods which partially resolves issue #1 also. CraftBukkit made the cloning problem even worse, but Vanilla does pre clone too, so the concept is valid in Vanilla
- For the .update call, if switching off using the manipulation methods, some of the .update() calls are now handled, but in TileEntityHopper.c(IInventory, ItemStack, int, EnumDirection) method where the actual inventory manipulation takes place, iinventory.setItem() where itemstack1 is null can also trigger .update() on chests. adding some method to setWithoutUpdate instead on the interface is possibly the most ideal instead of my hack method.
- For Hopper Suck In, Instead, ItemStacks could instead look for hoppers to ping them to suck them in, which can do much more efficient Tile Entity BlockPosition lookups. But would still need an Entity AABB for the Minecarts, but the overall occurrence would drastically be reduced.
- Hoppers are able to engage the automatic loot filling on a chest. However no reason to run that check multiple times, just do it on first index only
- Hoppers in 1.13+ (or at least 1.15) are now sucking in twice, once for each part of the complex shape of a Hopper. Bowl level pixel perfect bounding boxes are unnecessary. Restore the single AABB lookup from 1.12
- Removal of all usages of Streams. hoppers are hot. Streams have overhead that added up quite a lot and also seems to hurt JVM optimizations. Since MC runs on java 8, which is not receiving performance improvements to Streams/JIT, this hurts. This includes isEmpty() in Lootable.
- Skip item suck in behavior if the block above the hopper is full cuboid solid at all. Items collide with blocks and this scenario should never naturally occur where an item phases into a solid block and then gets sucked in. ( https://github.com/PaperMC/Paper/blob/10502558e92f478e7e1343193dd8ace8dbf8ac78/Spigot-Server-Patches/0414-Optimize-Hoppers.patch#L453 )
- Since .getItem() on some inventories (Lootable types) have additional overhead, keep result from first call and pass it to dependent methods
I run a decent sized Minecraft server that tries to not restrict players as much as possible.
My players love to build redstone contraptions, including item sorters and movers, resulting in LOTS of Hoppers, sometimes hitting 40,000+ Tile Entities, or 2000 Hoppers in a single area.
This has drastic impact to server performance causing every players experience to be degraded by loss of TPS.
After EXTENSIVE research using a profiler and studying the code, I've identified numerous issues with the hopper system.
- Hoppers by proper design, call the .update() method on an inventory when it has been modified in some way, to trigger physics and comparators.
However, many inventory manipulation methods also call .update()
This results in .update being called many times, which then triggers comparators and other physics events. This single handedly crushes servers with hoppers.- Unnecessary ItemStack cloning
The server calls itemstack.clone() on EVERY item stack it 'trys'. Take TileEntityHopper.a(IHopper) for example.
If an inventory of say 50 items in a chest is trying to be moved to a hopper, and that hopper only has 1 free slot and nothing matches the chests inventory, this method will result in every one of those item stacks being cloned every tick, only for it to fail to be moved and now an instance of the itemstack will be GC'd- Inefficient Item Suck In behavior
Hoppers will out-number ItemStacks in any matured world, and has potential to be loaded longer term than an item stack. It does not make sense that hoppers perform AABB lookups for Entities.
As of 1.13-1.15, this now also does 2 lookups per hopper due to the advanced hitbox. This needs to be a simple lookup again.
Also, no reason to suck in if there is a full solid occluding block above the hopper.- Usage of streams hurts performance due to overhead, complex call stacks. JVM does better at optimizing non stream code, and Java 8 is not receiving stream optimizations.
Solutions:
First I will reference my patch on how I quick patched in solutions, though not always perfect - note there are some non vanilla matters here but will lay out the vanilla relevant elements:
https://github.com/PaperMC/Paper/blob/10502558e92f478e7e1343193dd8ace8dbf8ac78/Spigot-Server-Patches/0414-Optimize-Hoppers.patch
- For cloning issue, I suggest using itemstack count manipulation like I am doing in my patch. This avoids calls to .update() from split stack methods which partially resolves issue #1 also. CraftBukkit made the cloning problem even worse, but Vanilla does pre clone too, so the concept is valid in Vanilla
- For the .update call, if switching off using the manipulation methods, some of the .update() calls are now handled, but in TileEntityHopper.c(IInventory, ItemStack, int, EnumDirection) method where the actual inventory manipulation takes place, iinventory.setItem() where itemstack1 is null can also trigger .update() on chests. adding some method to setWithoutUpdate instead on the interface is possibly the most ideal instead of my hack method.
- For Hopper Suck In, Instead, ItemStacks could instead look for hoppers to ping them to suck them in, which can do much more efficient Tile Entity BlockPosition lookups. But would still need an Entity AABB for the Minecarts, but the overall occurrence would drastically be reduced.
- Hoppers are able to engage the automatic loot filling on a chest. However no reason to run that check multiple times, just do it on first index only
- Hoppers in 1.13+ (or at least 1.15) are now sucking in twice, once for each part of the complex shape of a Hopper. Bowl level pixel perfect bounding boxes are unnecessary. Restore the single AABB lookup from 1.12
- Removal of all usages of Streams. hoppers are hot. Streams have overhead that added up quite a lot and also seems to hurt JVM optimizations. Since MC runs on java 8, which is not receiving performance improvements to Streams/JIT, this hurts. This includes isEmpty() in Lootable.
- Skip item suck in behavior if the block above the hopper is full cuboid solid at all. Items collide with blocks and this scenario should never naturally occur where an item phases into a solid block and then gets sucked in. ( https://github.com/PaperMC/Paper/blob/10502558e92f478e7e1343193dd8ace8dbf8ac78/Spigot-Server-Patches/0414-Optimize-Hoppers.patch#L453 )
- Since .getItem() on some inventories (Lootable types) have additional overhead, keep result from first call and pass it to dependent methods
Can you reproduce this bug in 1.16 pre release 5?
Can you reproduce this bug in 1.16 pre release 5?
![[Mod] Jarl-Penguin](../../../data/avatars/users/92849.png){kind=small}
![[Mod] Chandler](../../../data/assets/gravatar/triwonder81.png){kind=small}
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
Please do not mark unreleased versions as affected.
You don't have access to them yet.
— I am a robot. This action was performed automatically.
I can confirm the hopper issues are still an issue in the 1.9 release
updated versions.
The duplicate Hopper.update() call was resolved, but the other issues are still an issue (confirmed as of 1.12.2)
in the method that pushes items into another inventory
Latest 1.15 patch, these notes are for most part all still relevant: https://github.com/PaperMC/Paper/blob/10502558e92f478e7e1343193dd8ace8dbf8ac78/Spigot-Server-Patches/0414-Optimize-Hoppers.patch
Since you are the reporter, can you please update the description accordingly? Otherwise this might get lost in the comments.
I have updated the ticket with lots of 1.15 relevant information.
@Aikar this still happens in 20w27a?
@TPEHEP You don't have to keep asking me this. The developers will update this ticket if they've made progress.
It's up to the developers to note if they fully solved each item I raised. I will update ticket if I detect they made progress as I apply our patches.
Oh, okay
In 20w29a
Can confirm in 1.19.3 and 23w03a