MC-117075Performance issue with unloading large number of block entities
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
How to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntities
After replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
After discussing this with others, we think the best solution is to break up these lists so they are indexed by chunk.
That way, an unloaded chunk can just drop its ticking list and there is no slow remove on a giant list.
It could also make finding nearby entities more efficient.
Linked Issues
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
NormalCreated Issue:
Performance issue with unloading large number of block entities
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce:
Create a new superflat world and /tp 0 ~ 0
Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
Fly away, witness huge lag spikes when block entities begin to be unloaded.Sampling results looks like this: list.png
Code analysis: (using MCP names)
Several fields in World.java use List where Set would have much better time complexity.
These fields are used exactly like Sets, only calling add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList
net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
Attachments2
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce:
Create a new superflat world and /tp 0 ~ 0
Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
Fly away, witness huge lag spikes when block entities begin to be unloaded.Sampling results looks like this: list.png
Code analysis: (using MCP names)
Several fields in World.java use List where Set would have much better time complexity.
These fields are used exactly like
Sets, only calling add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList
net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List where Set would have much better time complexity.
These fields are used exactly like Sets, only calling add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
is duplicated by
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List where Set
would have much bettertime complexity.These fields are used exactly like Sets
, only calling add, remove, removeAll, and iterators:net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
Activity
All
Comments
History
Activity
Transitions
Permalink Edit Delete
mezz mezz added a comment - 21/May/17 1:05 PM
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
Activity
All
Comments
History
Activity
Transitions
Permalink Edit Delete
mezz mezz added a comment - 21/May/17 1:05 PMThe bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
After discussing this with others, we think the best solution is to break up these lists so they are indexed by chunk.
That way, an unloaded chunk can just drop its ticking list and there is no slow remove on a giant list.
It could also make finding nearby entities more efficient.
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
After discussing this with others, we think the best solution is to break up these lists so they are indexed by chunk.
That way, an unloaded chunk can just drop its ticking list and there is no slow remove on a giant list.
It could also make finding nearby entities more efficient.
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
After discussing this with others, we think the best solution is to break up these lists so they are indexed by chunk.
That way, an unloaded chunk can just drop its ticking list and there is no slow remove on a giant list.
It could also make finding nearby entities more efficient.
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
After discussing this with others, we think the best solution is to break up these lists so they are indexed by chunk.
That way, an unloaded chunk can just drop its ticking list and there is no slow remove on a giant list.
It could also make finding nearby entities more efficient.
is duplicated by
Performance Test.zip
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
Stepsto reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
After discussing this with others, we think the best solution is to break up these lists so they are indexed by chunk.
That way, an unloaded chunk can just drop its ticking list and there is no slow remove on a giant list.
It could also make finding nearby entities more efficient.The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent unloading them from a list in the world. This happens when you have a huge number of block entities and leave the area.
How to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of block entities spread over a few chunks: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
- Fly away, witness huge lag spikes when block entities begin to be unloaded
Sampling results looks like this: list.png
Code analysis (using MCP names)
Several fields in World.java use List methods with very bad time complexity.
These fields are using add, remove, removeAll, and iterators:
net.minecraft.world.World#loadedTileEntityList net.minecraft.world.World#tickableTileEntitiesAfter replacing those two Lists with Set, there is no lag spike and the sampling results look much better: set.png
After discussing this with others, we think the best solution is to break up these lists so they are indexed by chunk.
That way, an unloaded chunk can just drop its ticking list and there is no slow remove on a giant list.
It could also make finding nearby entities more efficient.
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Can confirm for 1.16 pre release 5
![[Mod] Chandler](../../../data/assets/gravatar/triwonder81.png){kind=small}
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
Forward resolving to MC-117075.
Thank you for your report!
However, this issue is a Duplicate of MC-117075.
It has been linked to this report. If you have additional information, please add it to that report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
The bug
Very large amounts of block entities (in this case, furnaces) cause intense server-side lag (MC-117075) and use up excessive memory. This will cause the world or certain chunks to fail to save or corrupt, and the game to run out of memory and crash. This does not happen on superflat worlds with furnaces.
To reproduce
1. Create a new world and switch to spectator mode.
2. Execute /fill ~50 ~ ~50 ~-50 ~2 ~-50 furnace and create multiple layers of tens of thousands of furnaces in the world.
3. Continue to execute the commands up to y=255 until about a million furnaces are placed.
4. Notice how extreme lag occurs, and observe the Mem usage steadily going up.
5. Quit the world.
6. 
The world will get stuck in the saving world screen, until failing to save and crashing due to java.lang.OutOfMemoryError: Java heap space.
Might relate to MC-117075.
After discussing this with others, we think the best solution is to break up these lists so they are indexed by chunk.
That way, an unloaded chunk can just drop its ticking list and there is no slow remove on a giant list.
It could also make finding nearby entities more efficient.
Still affects 1.15, both server and client-side
Can confirm for 1.16 pre release 5
still happens in 20w27a
Can reproduce in 1.17 Release Candidate 2.
Can confirm in 1.17.1.
Can confirm in 21w39a.
21w44a
This bug was fixed in 1.18. BlockEntity are now removed by iterator.remove()
Marking as Cannot Reproduce then. I tested and got some lag spikes, but I think they're just from
MC-162253. I will reopen this if anyone is still able to reproduce this.