mezz
- mezz
- mezz
- Asia/Tokyo
- Yes
- No
MC-103403![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Felix Jones](../../../data/avatars/users/40484.png){kind=small}
The bug
When there are extreme numbers of block entities (even non-ticking) a lot of time can be spent calling the class.getSimpleName() for the profiler, even though the profiler is not active.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of ticking block entities: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
Sampling results looks like this: getSimpleName.png
Code analysis (using MCP names)
In World.java there is a profiler section around each Block Entity's update call.
this.theProfiler.startSection(tileentity.getClass().getSimpleName()); ((ITickable)tileentity).update(); this.theProfiler.endSection();Internally, profiler code is wrapped in if (this.profilingEnabled) statements, but this call to getSimpleName() is not, and it can have an impact.
The bug
When there are
extreme numbers of block entities (evennon-ticking) a lot of timecan bespent calling the class.getSimpleName() for the profiler, even though the profiler is not active.Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of ticking block entities: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
Sampling results looks like this: getSimpleName.png
Code analysis (using MCP names)
In World.java there is a profiler section around each Block Entity's update call.
this.theProfiler.startSection(tileentity.getClass().getSimpleName()); ((ITickable)tileentity).update(); this.theProfiler.endSection();Internally, profiler code is wrapped in if (this.profilingEnabled) statements, but this call to getSimpleName() is not, and it can have an impact.
The bug
When there are large numbers of ticking block entities (even when they have no work to do) a lot of time is spent calling the class.getSimpleName() for the profiler, even though the profiler is not active.
Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of ticking block entities: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
Sampling results looks like this: getSimpleName.png
Code analysis (using MCP names)
In World.java there is a profiler section around each Block Entity's update call.
this.theProfiler.startSection(tileentity.getClass().getSimpleName()); ((ITickable)tileentity).update(); this.theProfiler.endSection();Internally, profiler code is wrapped in if (this.profilingEnabled) statements, but this call to getSimpleName() is not, and it can have an impact.
The bug
When there are large numbers of ticking block entities
(even when they have no work to do)a lot of time is spent calling the class.getSimpleName() for the profiler, even though the profiler is not active.Steps to reproduce
- Create a new superflat world and /tp 0 ~ 0
- Create a lot of ticking block entities: /fill 0 ~ 0 100 ~2 100 minecraft:furnace
Sampling results looks like this: getSimpleName.png
Code analysis (using MCP names)
In World.java there is a profiler section around each Block Entity's update call.
this.theProfiler.startSection(tileentity.getClass().getSimpleName()); ((ITickable)tileentity).update(); this.theProfiler.endSection();Internally, profiler code is wrapped in if (this.profilingEnabled) statements, but this call to getSimpleName() is not, and it can have an impact.
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.
GuiContainer key handler methods return true even whenkeyis not handledGuiContainer key and mouse handler methods return true even when input is not handled
In 1.13.2 the key handler methods for GUIs return `true` when the
keyis handled, basically so thekeyevent is "consumed" and other things don't use it.Most GUIs return the right value, but `GuiContainer#keyPressed` (mcp name) always returns `true`, and so
it doesnot report ifit actually handled thekeyor not.In 1.13.2 the key and mouse handler methods for GUIs return `true` when the input is handled, basically so the input event is "consumed" and other things don't use it.
Most GUIs return the right value, but `GuiContainer#keyPressed` and `GuiContainer#mouseClicked` (mcp names ) always returns `true`, and so they do not report if they actually handled the input or not.
I selected it, which was a mistake.
I'm not sure why other people are arguing about it.
Thanks FVbico.
Thank you.
I think I wasn't able to find that issue because it says "mimap" in the title which is misspelled, it should be "mipmap".
Oh never mind, I see you reopened it. I was only searching open issues.
I confirmed this is still an issue in 1.10.2, but I cannot check snapshots because Forge is only available for release versions. Is that ok?
I am only using Forge to look at the code in a convenient way, this issue exists in vanilla.
I contribute code to Forge. It does not edit this class, this is a vanilla issue.
Here is the obfuscated code from the 16w43a jar, confirming the bug without Forge.
Sorry for the edits, I initially confirmed with 16w42a instead of 16w43a.
Confirmed in 16w44a
Confirmed in 16w44a
Can this please be reconsidered as a minor bug?
Forcing Anistropic Filtering generally does not cause artifacts in other games.
I was able to force Anistropic Filtering some time ago without any visual artifacts (I think 1.6.4) and it really improved the look of distant textures in Minecraft.
I have confirmed this issue in 1.11.
There are two bugs:
To replicate this bug you can override the system (JVM) locale to French with these arguments on the command line:
-Duser.country=FR -Duser.language=fr
In all cases, the system (JVM) language should be ignored and the Minecraft language should be used for formatting.
With English language in Minecraft, and French system language, numbers should be formatted like this: "1,000,000" and "1.00" but they show up with the format "1,000,000" and "1,00" instead.
With French language in Minecraft, and English system language, the numbers should be formatted like this: "1 000 000" and "1,00" but they show up with the format "1,000,000" and "1,00" instead.
When this issue is fixed, the French non-breaking-spaces will be used properly and it will expose this bug as well: https://bugs.mojang.com/browse/MC-2595
In snapshot 16w50a the behavior is different but still incorrect:
Every number format is Locale.US style and ignores both the system (JVM) language and the Minecraft language.
When the Minecraft language is set to French it should display numbers like "1 000 000" and "1,00" but instead it uses the US style "1,000,000" and "1.00".
Confirmed in snapshot 16w50a
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.
This has been recently fixed in Forge for 1.12. The code might be useful for analysis of this bug.
https://github.com/MinecraftForge/MinecraftForge/commit/32e811bd7a72efc59dd05c89775e62de908070ce
This was fixed in 1.12 during the move to data driven recipes.
I misinterpreted the purpose of this return value. There is no bug, please close this issue.