In my opinion, the new things are nice, but this is the update which added chat reporting.
we got boats in chests, I guess that's helpful? I mean, it means we don't have to build stupidly large and complex minecart systems to move items around now without the ender chest or shulker boxes. But yeah I see what you mean, I have a friend who had a previous lengthy suspension from Xbox Live for telling other's not to send her rude messages and I've lost trust in the Enforcement Team, I can protect her against this on my Minecraft server because it is private
but unfortunately this will negatively affect a lot of other people.
I mean imagine the nonsense that will happen now, suspensions for swearing, or making a joke about something that wasn't a bomb prank or anything that serious. I understand we need rules to protect people, but some of the things people get suspended for is ludicrous and after seeing a friend get screwed by the moderation team on Xbox Live I am very cautious about these people and have since advised her not to reply to people who bother her in future, just block them, as I plan on doing the same.
This is because most modders couldn't care less about optimization; "well, it works, which is all that matters", and modloader-based mods have to be loaded and constructed at run time; it takes me less than 5 seconds to launch TMCWv5 and load a world and 2/3 of that time isn't even the game itself but because of the launcher, which took only about a second to load (measured from the time the launcher says it is starting the game and the game says it is loading resources, it is actually a bit longer as it doesn't say when it finished. The world load time is also significantly reduced since I disabled spawn chunks, so it only had to load 289 chunks instead of 914 (actually, vanilla 1.6.4 would load 1066 chunks due to the view distance being 10 regardless of render distance, though this doesn't mean it is 3.7 times slower as the JVM has to load the server classes and the server has to initialize stuff):
// Clicked on "Play" in launcher (3.1 seconds)
[Info: 2022-11-10-02:23:48.0391971: GameCallbacks.cpp(228)] Launcher/launcher (main) Warn Have local file <MINECRAFT_PROFILE_ID>\.minecraft\versions\TMCWv5\TMCWv5.jar but don't know what size or hash it should be. Have to assume it's good.
[Info: 2022-11-10-02:23:49.1040973: GameCallbacks.cpp(228)] Launcher/launcher (main) Info Minecraft client TMCWv5 is ready to start.
// Note - https://bugs.mojang.com/browse/MCL-4334 (assets are reinstalled every time game is launched; this does not occur in MCP)
[Info: 2022-11-10-02:23:49.1235887: GameCallbacks.cpp(228)] Launcher/launcher (main) Debug Reconstructing virtual assets!
[Info: 2022-11-10-02:23:51.1409120: GameCallbacks.cpp(228)] Launcher/launcher (main) Debug Asset <MINECRAFT_PROFILE_ID>\.minecraft\assets\objects\15\15f38314274e759c44f50ac641d11bde12474a25 to <MINECRAFT_PROFILE_ID>\.minecraft\assets\virtual\legacy\sounds\music\menu\menu4.ogg
// Starting game (1.07 seconds)
[Info: 2022-11-10-02:23:51.1445641: ClientStarter.cpp(950)] Starting game in folder %USERPROFILE%\AppData\Roaming\.minecraft\TMCW using java executable C:\...\javaw.exe
[Info: 2022-11-10-02:23:51.6372452: GameCallbacks.cpp(228)] Game/game () Info 2022-11-09 20:23:51 [CLIENT] [INFO] Setting user: <MINECRAFT_PROFILE_NAME>
[Info: 2022-11-10-02:23:52.2125230: GameCallbacks.cpp(228)] Game/game () Info 2022-11-09 20:23:52 [CLIENT] [INFO] Reloading ResourceManager: Default
// Loading world (0.67 seconds)
[Info: 2022-11-10-02:24:04.4923515: GameCallbacks.cpp(228)] Game/game () Info 2022-11-09 20:24:04 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
[Info: 2022-11-10-02:24:04.4927947: GameCallbacks.cpp(228)] Game/game () Info 2022-11-09 20:24:04 [SERVER] [INFO] Generating keypair
[Info: 2022-11-10-02:24:05.1587194: GameCallbacks.cpp(228)] Game/game () Info loading single player
[Info: 2022-11-10-02:24:05.1588961: GameCallbacks.cpp(228)] Game/game () Info 2022-11-09 20:24:05 [SERVER] [INFO] <MINECRAFT_PROFILE_NAME>[/127.0.0.1:0] logged in with entity id 1 at (-983.9359339754636, 20.000000001, -913.855475138669)
[Info: 2022-11-10-02:24:05.1617675: GameCallbacks.cpp(228)] Game/game () Info 2022-11-09 20:24:05 [SERVER] [INFO] <MINECRAFT_PROFILE_NAME> joined the game
// Total time = 4.84 seconds; 2/3 of this was the launcher "preparing" the game
Also, Mojang doesn't care either - they closed this bug report, which quadruples the time it takes for the game to launch, as "cannot reproduce" but it is very easy to reproduce; just try modding the jar directly without making the changes they show (aside from renaming the version, as has been the case since mid-2013 and was sufficient back then, you have to delete a "downloads" section from the json) and see if it isn't refreshed when you click on play. Also, the assets, at least the "legacy" assets, are recreated every time I launch the game, as clearly seen by the modification time and the launcher output:
Yeah, I wasn't even able to run the 1.12 modded server he had up on my current laptop. Sucks to suck, I guess.
i was playing minecraft on 1.19.3 until i found this seed called 1637241643345969136 in the seed there is a ruined portal underneath sands and some magma and netherrack are also seen underneath some sand and these are the images i found
i was playing minecraft on 1.19.3 i found this seed called 1637241643345969136 in the seed there is a ruined portal underneath sands and some magma and netherrack are also seen underneath some sand and these are the images i found
Yeah, I wasn't even able to run the 1.12 modded server he had up on my current laptop. Sucks to suck, I guess.
In response to TMC, I think whether Minecraft is modded or not optimization matters anyway.
Computers do not have unlimited power and memory and people who make these programs and put them out for the public to use should be putting more effort into making sure they take a no nonsense approach to their software development.
The amount of money that gets wasted on unnecessary hardware upgrades is a problem, people have constantly seen little to no performance benefit even when upgrading from existing hardware that was having trouble with Minecraft. This is why a friend I know who has an Nvidia RTX 3060 video card still experienced lag when he played on my Minecraft server, and I am not talking network lag here, it's not the connection, he says it happens around my base build, exactly what happens to everyone else who plays on it, when away from the base, Minecraft fps returns to normal, above 60-120fps.
Seeing as chests count as entities in the game, they cause lag, but my chests in the factory build are not even connected to any redstone contraption and are only ever used at the point of being opened, which is when an animation of them would be initiated. So it makes no sense why they would be the cause of tanking a person's fps. All chests need to do if not connected to a hopper or any other redstone block is store your items, which is handled by the save file and the memory of the system.
There is clearly an extreme inefficiency with the way chests are handled in the vanilla game which wasn't even fixed in the current version of the game.
But this is not the only example of bad optimization that exists in 1.19.
The game could very likely benefit from much optimizing, but saying that a graphics card upgrade brings no benefits isn't a good example of why. I know it's easy to make fun of Minecraft for being unoptimized but it's not likely that it wouldn't be a CPU heavy game anyway.
It's worth pointing out that CPU heavy does not necessarily mean inefficient or unoptimized. One can be both as they're not mutually exclusive things. So making Minecraft more efficient isn't necessarily going to remove the fact that it's CPU reliant.
The game could very likely benefit from much optimizing, but saying that a graphics card upgrade brings no benefits isn't a good example of why. I know it's easy to make fun of Minecraft for being unoptimized but it's not likely that it wouldn't be a CPU heavy game anyway.
It's worth pointing out that CPU heavy does not necessarily mean inefficient or unoptimized. One can be both as they're not mutually exclusive things. So making Minecraft more efficient isn't necessarily going to remove the fact that it's CPU reliant.
I should've clarified the fact that this friend who upgraded his GPU also did it on a newer build entirely, he also has an AMD Ryzen 5600 like I do and he went from a Piledriver FX8370 CPU. Having an almost, but not quite top tier consumer model desktop CPU does indeed demonstrate there is a problem with the game itself when the upgrade didn't do much for him, despite the vastly superior benchmark scores in areas where differences can be shown.
Minecraft being CPU dependent doesn't excuse the fact that more could be done to make it run better on people's PC's. TMC has also given examples where people who created mods for the game have managed to make it run better or increase the overall frame rate of the game.
It's not an optimized game, bedrock edition does show better results when compared to Java, but they both have problems which need sorting out and like I mentioned before, it's easy to pin the blame on a person's PC instead of looking what more could be done to make the game more efficient.
There is clearly an extreme inefficiency with the way chests are handled in the vanilla game which wasn't even fixed in the current version of the game.
I've explained multiple times before (elsewhere) that this has absolutely nothing to do with anything other than the actual rendering of chests (I did discover one case which eventually leads to a crash / extreme lag, as described below, but you'd never encounter it in any real-world situation), not whether they are tile entities. In fact, here is a quarter-million(!) tile entities in the form of barrels, which are almost exactly the same as chests, except they don't link up to form double chests (which are actually better for rendering than individual chests since the game only renders a single model for each pair instead of each chest):
If slabs were tile entities, this would all be possible quite easily, but tile entities add to the memory Minecraft needs to use and could potentially cause lag. However, is that really a big deal, or just hyperbole?
Now, I can't really give a definitive answer (I would have tried creating a mod to test it, but my computer won't work for it), but I did make an experiment once in which I tested the performance costs of tile entities.
First, I created a completely empty Superflat world. Then, I filled an entire chunk (16x16x256, 65,536 blocks) with dirt, a block that does nothing. I got a small blip of lag and an increase of memory usage, as the /fill commands were executed and Minecraft saved the data, which quickly subsided. I then replaced that chunk with furnaces, a tile entity that does nothing when not burning fuel. Again, a small blip of lag and memory increase, but the performance quickly returned to normal. I then did the same thing with hoppers, which had a similar effect, but a small amount of my fps drop and increased memory usage lingered due to the hoppers constantly ticking and checking what was in each other's inventory.
So, in other words, even on potato machines like mine, tile entities that do nothing don't really contribute to performance loss all that much. And really, does the average person use more than 65k slabs in any build?
Actually, I found a much more serious issue with chests - they caused chunks to load infinitely on the server, eventually reaching thousands and crashing due to running out of memory if left unchecked, which appears to be due to the double chest code, which checks for blocks adjacent to them, which may be in unloaded chunks, so the game loads them:
In the following three screenshots you can see one or two double chests which are rendering at the corner of a loaded chunk; most are not being rendered since the rendering code breaks if there are more than two chests (this is one reason why you can't / couldn't place multiple chests next to each other; this was changed in a newer version):
There are now 2647 chunks loaded server-side, and still increasing, if at a slower rate as server tick time goes through the roof (not exactly sure why since the same logic is being executed by both sides, there is likely recursion going on; the client tick is still only 2 ms, with a total of 71680 TESRs registered, equivalent to 280 chunks with a layer of chests, which is how many are loaded client-side; on the server-side there were 2647 * 256 = 677,632 chests loaded):
As seen here there actually are chests where nothing seems to be (you can see a block selection outline above):
This is a rendering of the world; chunks had loaded in a diamond pattern as opposed to the normal square:
This is basically an example of "worldgen runaway", when blocks placed during world generation cause adjacent chunks to load, except even if I reloaded the world, only loading already generated chunks, it did the same thing since chests are actively updated:
Also, this is the code that chests execute every tick; barrels are almost the same except I removed the call to "checkForAdjacentChests" and they update their metadata when opening/closing:
Note also that nothing actually rendered, aside from a double chest or two at the corner of loaded chunks, since the rendering code breaks if there are more than two chests next to each other, so the effect on FPS wasn't actually that bad, but still significant since it had to iterate through a list of tens of thousands of TESRs every frame (I remember doing this in vanilla before and it crashed the game; either way, Mojang considers using such silly Superflat presets to be invalid and the recursion(?) issue wouldn't be a problem with normal usage).
Also, I was able to fix the infinite chunk loading and server lag with a one-line change; I'd previously added methods which only access loaded chunks, used by things like entities to prevent them from loading chunks and by simply using it for chests it stopped the issues, though performance was still significantly impacted (FPS, since again the game has to iterate through over 70,000 TESRs per frame, even if nothing is actually being rendered, but again, that is a quite extreme number of chests, or anything else that might use a TESR, plus I still get 3 times the capped framerate with Vsync enabled, so who cares (I actually still do but many developers seem to think if it is good enough for them it is good enough for everybody):
private TileEntityChest getAdjacentChest(int x, int y, int z, int dir)
{
// Changed from getBlockId to getLoadedBlockId
Block b = Block.blocksList[this.worldObj.getLoadedBlockId(x, y, z)];
if (b instanceof BlockChestFix && ((BlockChest)b).chestType == this.getChestType())
{
TileEntity te = this.worldObj.getBlockTileEntity(x, y, z);
if (te instanceof TileEntityChestFix)
{
((TileEntityChestFix)te).checkAdjacentChest(this, dir);
return (TileEntityChest)te;
}
else
{
this.adjacentChestChecked = false;
}
}
return null;
}
// Removed check for !loadChunkOnProvideRequest, which is unnecessary as it is always true, and uses
// LongHashMapFix.getChunk, which returns a default empty chunk instead of null for unloaded chunks.
public Chunk provideChunk(int chunkX, int chunkZ)
{
Chunk chunk = this.loadedChunkMap.getChunk(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ));
return (chunk != Chunk.EMPTY_CHUNK ? chunk : this.loadChunk(chunkX, chunkZ));
}
// Similar to provideChunk but returns a default empty chunk if a chunk isn't loaded (same behavior as
// WorldClient.provideChunk)
public Chunk getLoadedChunk(int chunkX, int chunkZ)
{
return this.loadedChunkMap.getChunk(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ));
}
I should also note that while chests still increased the tick time it was still less than 3 ms out of a maximum of 50 ms (so less than 6% CPU usage; even my old computer, with an ancient CPU from 2005, would have no issues keeping up - even the latest CPUs are only around 5 times faster in single--thread performance, with my current computer being in between) and regular (mob) entities are hundreds of times worse (300 chickens took about 3.5 ms, or 11667 ns each; 73894 chests took about 2.43 ms, or 33 ns each - a factor of 353 lower), as well as much worse in terms of FPS due to their more complex models and rendering (chests actually sue the same rendering code but they do not have any rotations, except when the lid opens and closes, so that eliminates a lot of OpenGL translations (the model renderer also checks before calling glRotatef / glTranslatef so my closed chest optimization is mainly due to rendering the whole model as a single piece instead of 3 separate pieces):
The baseline server tick time is about 0.3 ms (the times I calculated for chickens and chest used the total minus this):
300 chickens:
4096 chests (2048 double chests, not a direct comparison as there are more chunks in view so baseline FPS is lower, but this does show how mob entities are much worse, by more than a dozen times in terms of FPS):
Vanilla 1.6.4 gets only about half the FPS because of an optimization I made to simplify the rendering of closed chests:
I've explained multiple times before (elsewhere) that this has absolutely nothing to do with anything other than the actual rendering of chests (I did discover one case which eventually leads to a crash / extreme lag, as described below, but you'd never encounter it in any real-world situation), not whether they are tile entities. In fact, here is a quarter-million(!) tile entities in the form of barrels, which are almost exactly the same as chests, except they don't link up to form double chests (which are actually better for rendering than individual chests since the game only renders a single model for each pair instead of each chest):
Actually, I found a much more serious issue with chests - they caused chunks to load infinitely on the server, eventually reaching thousands and crashing due to running out of memory if left unchecked, which appears to be due to the double chest code, which checks for blocks adjacent to them, which may be in unloaded chunks, so the game loads them:
In the following three screenshots you can see one or two double chests which are rendering at the corner of a loaded chunk; most are not being rendered since the rendering code breaks if there are more than two chests (this is one reason why you can't / couldn't place multiple chests next to each other; this was changed in a newer version):
There are now 2647 chunks loaded server-side, and still increasing, if at a slower rate as server tick time goes through the roof (not exactly sure why since the same logic is being executed by both sides, there is likely recursion going on; the client tick is still only 2 ms, with a total of 71680 TESRs registered, equivalent to 280 chunks with a layer of chests, which is how many are loaded client-side; on the server-side there were 2647 * 256 = 677,632 chests loaded):
As seen here there actually are chests where nothing seems to be (you can see a block selection outline above):
This is a rendering of the world; chunks had loaded in a diamond pattern as opposed to the normal square:
This is basically an example of "worldgen runaway", when blocks placed during world generation cause adjacent chunks to load, except even if I reloaded the world, only loading already generated chunks, it did the same thing since chests are actively updated:
Also, this is the code that chests execute every tick; barrels are almost the same except I removed the call to "checkForAdjacentChests" and they update their metadata when opening/closing:
Note also that nothing actually rendered, aside from a double chest or two at the corner of loaded chunks, since the rendering code breaks if there are more than two chests next to each other, so the effect on FPS wasn't actually that bad, but still significant since it had to iterate through a list of tens of thousands of TESRs every frame (I remember doing this in vanilla before and it crashed the game; either way, Mojang considers using such silly Superflat presets to be invalid and the recursion(?) issue wouldn't be a problem with normal usage).
Also, I was able to fix the infinite chunk loading and server lag with a one-line change; I'd previously added methods which only access loaded chunks, used by things like entities to prevent them from loading chunks and by simply using it for chests it stopped the issues, though performance was still significantly impacted (FPS, since again the game has to iterate through over 70,000 TESRs per frame, even if nothing is actually being rendered, but again, that is a quite extreme number of chests, or anything else that might use a TESR, plus I still get 3 times the capped framerate with Vsync enabled, so who cares (I actually still do but many developers seem to think if it is good enough for them it is good enough for everybody):
private TileEntityChest getAdjacentChest(int x, int y, int z, int dir)
{
// Changed from getBlockId to getLoadedBlockId
Block b = Block.blocksList[this.worldObj.getLoadedBlockId(x, y, z)];
if (b instanceof BlockChestFix && ((BlockChest)b).chestType == this.getChestType())
{
TileEntity te = this.worldObj.getBlockTileEntity(x, y, z);
if (te instanceof TileEntityChestFix)
{
((TileEntityChestFix)te).checkAdjacentChest(this, dir);
return (TileEntityChest)te;
}
else
{
this.adjacentChestChecked = false;
}
}
return null;
}
// Removed check for !loadChunkOnProvideRequest, which is unnecessary as it is always true, and uses
// LongHashMapFix.getChunk, which returns a default empty chunk instead of null for unloaded chunks.
public Chunk provideChunk(int chunkX, int chunkZ)
{
Chunk chunk = this.loadedChunkMap.getChunk(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ));
return (chunk != Chunk.EMPTY_CHUNK ? chunk : this.loadChunk(chunkX, chunkZ));
}
// Similar to provideChunk but returns a default empty chunk if a chunk isn't loaded (same behavior as
// WorldClient.provideChunk)
public Chunk getLoadedChunk(int chunkX, int chunkZ)
{
return this.loadedChunkMap.getChunk(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ));
}
I should also note that while chests still increased the tick time it was still less than 3 ms out of a maximum of 50 ms (so less than 6% CPU usage; even my old computer, with an ancient CPU from 2005, would have no issues keeping up - even the latest CPUs are only around 5 times faster in single--thread performance, with my current computer being in between) and regular (mob) entities are hundreds of times worse (300 chickens took about 3.5 ms, or 11667 ns each; 73894 chests took about 2.43 ms, or 33 ns each - a factor of 353 lower), as well as much worse in terms of FPS due to their more complex models and rendering (chests actually sue the same rendering code but they do not have any rotations, except when the lid opens and closes, so that eliminates a lot of OpenGL translations (the model renderer also checks before calling glRotatef / glTranslatef so my closed chest optimization is mainly due to rendering the whole model as a single piece instead of 3 separate pieces):
The baseline server tick time is about 0.3 ms (the times I calculated for chickens and chest used the total minus this):
300 chickens:
4096 chests (2048 double chests, not a direct comparison as there are more chunks in view so baseline FPS is lower, but this does show how mob entities are much worse, by more than a dozen times in terms of FPS):
Vanilla 1.6.4 gets only about half the FPS because of an optimization I made to simplify the rendering of closed chests:
If my frame rate was well above the refresh rate of my monitor at all times even with the number of chests and redstone contraptions in my factory build we wouldn't still be having this conversation, not where I complain about slowdown which happens not only for myself but all friends who play on my server, some who have better PC's than I do.
Bottlenecks are inevitable in PC builds, as are some frame rate dips, experience has taught me that much already.
If my frame rate was as high as 300fps, but dipped to 100fps in the most extreme situations, it wouldn't matter for me as it would still remain unnoticeable during normal gameplay, not with how G-Sync works as it aims to eliminate perceptible stuttering by making sure your monitor refresh rate matches the frame rate being fed to the monitor, a dynamic refresh rate if you will, 1 refresh = 1 frame, and nobody considers 100fps to be a bad frame rate either.
But despite upgrading my PC build from an older one which had a much slower CPU than my current one, I am still getting dips to around 50fps or less when around my base that has hundreds of chests in it, in the worst case scenario, even with very few apps running in the background, I've caught it going as low as 24fps, where the stuttering does become very noticeable. When this happens in the vanilla game, not with modpacks or anything like that, just the official game, even on PC builds with the Ryzen 5, something is very wrong.
And I don't see why I should have to manually overclock my 6 core CPU, risk burning it out just to get a marginal boost in performance.
16 chunks rendering distance setting, still the same issue, while bedrock edition may be more optimized than Java version, it isn't by much anymore,
because I am having to make do with pitiful render distances just as I did back when I played Java edition, just to make the game somewhat playable.
In my opinion, the new things are nice, but this is the update which added chat reporting.
we got boats in chests, I guess that's helpful? I mean, it means we don't have to build stupidly large and complex minecart systems to move items around now without the ender chest or shulker boxes. But yeah I see what you mean, I have a friend who had a previous lengthy suspension from Xbox Live for telling other's not to send her rude messages and I've lost trust in the Enforcement Team, I can protect her against this on my Minecraft server because it is private
but unfortunately this will negatively affect a lot of other people.
I mean imagine the nonsense that will happen now, suspensions for swearing, or making a joke about something that wasn't a bomb prank or anything that serious. I understand we need rules to protect people, but some of the things people get suspended for is ludicrous and after seeing a friend get screwed by the moderation team on Xbox Live I am very cautious about these people and have since advised her not to reply to people who bother her in future, just block them, as I plan on doing the same.
@princessgarnet
Yeah, I wasn't even able to run the 1.12 modded server he had up on my current laptop. Sucks to suck, I guess.
i was playing minecraft on 1.19.3 until i found this seed called 1637241643345969136 in the seed there is a ruined portal underneath sands and some magma and netherrack are also seen underneath some sand and these are the images i found
165 73 362 for coordinates on 1.19.0
614 62 842 shipwreck
400 62 660 ocean ruin
In response to TMC, I think whether Minecraft is modded or not optimization matters anyway.
Computers do not have unlimited power and memory and people who make these programs and put them out for the public to use should be putting more effort into making sure they take a no nonsense approach to their software development.
The amount of money that gets wasted on unnecessary hardware upgrades is a problem, people have constantly seen little to no performance benefit even when upgrading from existing hardware that was having trouble with Minecraft. This is why a friend I know who has an Nvidia RTX 3060 video card still experienced lag when he played on my Minecraft server, and I am not talking network lag here, it's not the connection, he says it happens around my base build, exactly what happens to everyone else who plays on it, when away from the base, Minecraft fps returns to normal, above 60-120fps.
Seeing as chests count as entities in the game, they cause lag, but my chests in the factory build are not even connected to any redstone contraption and are only ever used at the point of being opened, which is when an animation of them would be initiated. So it makes no sense why they would be the cause of tanking a person's fps. All chests need to do if not connected to a hopper or any other redstone block is store your items, which is handled by the save file and the memory of the system.
There is clearly an extreme inefficiency with the way chests are handled in the vanilla game which wasn't even fixed in the current version of the game.
But this is not the only example of bad optimization that exists in 1.19.
The game could very likely benefit from much optimizing, but saying that a graphics card upgrade brings no benefits isn't a good example of why. I know it's easy to make fun of Minecraft for being unoptimized but it's not likely that it wouldn't be a CPU heavy game anyway.
It's worth pointing out that CPU heavy does not necessarily mean inefficient or unoptimized. One can be both as they're not mutually exclusive things. So making Minecraft more efficient isn't necessarily going to remove the fact that it's CPU reliant.
I should've clarified the fact that this friend who upgraded his GPU also did it on a newer build entirely, he also has an AMD Ryzen 5600 like I do and he went from a Piledriver FX8370 CPU. Having an almost, but not quite top tier consumer model desktop CPU does indeed demonstrate there is a problem with the game itself when the upgrade didn't do much for him, despite the vastly superior benchmark scores in areas where differences can be shown.
Minecraft being CPU dependent doesn't excuse the fact that more could be done to make it run better on people's PC's. TMC has also given examples where people who created mods for the game have managed to make it run better or increase the overall frame rate of the game.
It's not an optimized game, bedrock edition does show better results when compared to Java, but they both have problems which need sorting out and like I mentioned before, it's easy to pin the blame on a person's PC instead of looking what more could be done to make the game more efficient.
I've explained multiple times before (elsewhere) that this has absolutely nothing to do with anything other than the actual rendering of chests (I did discover one case which eventually leads to a crash / extreme lag, as described below, but you'd never encounter it in any real-world situation), not whether they are tile entities. In fact, here is a quarter-million(!) tile entities in the form of barrels, which are almost exactly the same as chests, except they don't link up to form double chests (which are actually better for rendering than individual chests since the game only renders a single model for each pair instead of each chest):
Actually, I found a much more serious issue with chests - they caused chunks to load infinitely on the server, eventually reaching thousands and crashing due to running out of memory if left unchecked, which appears to be due to the double chest code, which checks for blocks adjacent to them, which may be in unloaded chunks, so the game loads them:
In the following three screenshots you can see one or two double chests which are rendering at the corner of a loaded chunk; most are not being rendered since the rendering code breaks if there are more than two chests (this is one reason why you can't / couldn't place multiple chests next to each other; this was changed in a newer version):
There are now 2647 chunks loaded server-side, and still increasing, if at a slower rate as server tick time goes through the roof (not exactly sure why since the same logic is being executed by both sides, there is likely recursion going on; the client tick is still only 2 ms, with a total of 71680 TESRs registered, equivalent to 280 chunks with a layer of chests, which is how many are loaded client-side; on the server-side there were 2647 * 256 = 677,632 chests loaded):
As seen here there actually are chests where nothing seems to be (you can see a block selection outline above):
This is a rendering of the world; chunks had loaded in a diamond pattern as opposed to the normal square:
This is basically an example of "worldgen runaway", when blocks placed during world generation cause adjacent chunks to load, except even if I reloaded the world, only loading already generated chunks, it did the same thing since chests are actively updated:
https://www.reddit.com/r/feedthebeast/comments/5x0twz/investigating_extreme_worldgen_lag/
Also, this is the code that chests execute every tick; barrels are almost the same except I removed the call to "checkForAdjacentChests" and they update their metadata when opening/closing:
public void updateEntity() { this.checkForAdjacentChests(); this.prevLidAngle = this.lidAngle; if (this.numUsingPlayers > 0 && this.lidAngle == 0.0F && this.adjacentChestZNeg == null && this.adjacentChestXNeg == null) { double var8 = (double)this.xCoord + (this.adjacentChestXPos != null ? 1.0D : 0.5D); double var11 = (double)this.zCoord + (this.adjacentChestZPosition != null ? 1.0D : 0.5D); this.worldObj.playSoundEffect(var8, (double)this.yCoord + 0.5D, var11, "random.chestopen", 0.5F, this.worldObj.rand.nextFloat() * 0.1F + 0.9F); } if (this.numUsingPlayers == 0 && this.lidAngle > 0.0F || this.numUsingPlayers > 0 && this.lidAngle < 1.0F) { float var9 = this.lidAngle; if (this.numUsingPlayers > 0) { this.lidAngle += 0.1F; if (this.lidAngle > 1.0F) this.lidAngle = 1.0F; } else { this.lidAngle -= 0.1F; if (this.lidAngle < 0.0F) this.lidAngle = 0.0F; } if (this.lidAngle < 0.5F && var9 >= 0.5F && this.adjacentChestZNeg == null && this.adjacentChestXNeg == null) { double var8 = (double)this.xCoord + (this.adjacentChestXPos != null ? 1.0D : 0.5D); double var11 = (double)this.zCoord + (this.adjacentChestZPosition != null ? 1.0D : 0.5D); this.worldObj.playSoundEffect(var8, (double)this.yCoord + 0.5D, var11, "random.chestclosed", 0.5F, this.worldObj.rand.nextFloat() * 0.1F + 0.9F); } } }Note also that nothing actually rendered, aside from a double chest or two at the corner of loaded chunks, since the rendering code breaks if there are more than two chests next to each other, so the effect on FPS wasn't actually that bad, but still significant since it had to iterate through a list of tens of thousands of TESRs every frame (I remember doing this in vanilla before and it crashed the game; either way, Mojang considers using such silly Superflat presets to be invalid and the recursion(?) issue wouldn't be a problem with normal usage).
Also, I was able to fix the infinite chunk loading and server lag with a one-line change; I'd previously added methods which only access loaded chunks, used by things like entities to prevent them from loading chunks and by simply using it for chests it stopped the issues, though performance was still significantly impacted (FPS, since again the game has to iterate through over 70,000 TESRs per frame, even if nothing is actually being rendered, but again, that is a quite extreme number of chests, or anything else that might use a TESR, plus I still get 3 times the capped framerate with Vsync enabled, so who cares (I actually still do but many developers seem to think if it is good enough for them it is good enough for everybody):
private TileEntityChest getAdjacentChest(int x, int y, int z, int dir) { // Changed from getBlockId to getLoadedBlockId Block b = Block.blocksList[this.worldObj.getLoadedBlockId(x, y, z)]; if (b instanceof BlockChestFix && ((BlockChest)b).chestType == this.getChestType()) { TileEntity te = this.worldObj.getBlockTileEntity(x, y, z); if (te instanceof TileEntityChestFix) { ((TileEntityChestFix)te).checkAdjacentChest(this, dir); return (TileEntityChest)te; } else { this.adjacentChestChecked = false; } } return null; } // Removed check for !loadChunkOnProvideRequest, which is unnecessary as it is always true, and uses // LongHashMapFix.getChunk, which returns a default empty chunk instead of null for unloaded chunks. public Chunk provideChunk(int chunkX, int chunkZ) { Chunk chunk = this.loadedChunkMap.getChunk(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ)); return (chunk != Chunk.EMPTY_CHUNK ? chunk : this.loadChunk(chunkX, chunkZ)); } // Similar to provideChunk but returns a default empty chunk if a chunk isn't loaded (same behavior as // WorldClient.provideChunk) public Chunk getLoadedChunk(int chunkX, int chunkZ) { return this.loadedChunkMap.getChunk(ChunkCoordIntPair.chunkXZ2Int(chunkX, chunkZ)); }I should also note that while chests still increased the tick time it was still less than 3 ms out of a maximum of 50 ms (so less than 6% CPU usage; even my old computer, with an ancient CPU from 2005, would have no issues keeping up - even the latest CPUs are only around 5 times faster in single--thread performance, with my current computer being in between) and regular (mob) entities are hundreds of times worse (300 chickens took about 3.5 ms, or 11667 ns each; 73894 chests took about 2.43 ms, or 33 ns each - a factor of 353 lower), as well as much worse in terms of FPS due to their more complex models and rendering (chests actually sue the same rendering code but they do not have any rotations, except when the lid opens and closes, so that eliminates a lot of OpenGL translations (the model renderer also checks before calling glRotatef / glTranslatef so my closed chest optimization is mainly due to rendering the whole model as a single piece instead of 3 separate pieces):
300 chickens:
4096 chests (2048 double chests, not a direct comparison as there are more chunks in view so baseline FPS is lower, but this does show how mob entities are much worse, by more than a dozen times in terms of FPS):
Vanilla 1.6.4 gets only about half the FPS because of an optimization I made to simplify the rendering of closed chests:
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
If my frame rate was well above the refresh rate of my monitor at all times even with the number of chests and redstone contraptions in my factory build we wouldn't still be having this conversation, not where I complain about slowdown which happens not only for myself but all friends who play on my server, some who have better PC's than I do.
Bottlenecks are inevitable in PC builds, as are some frame rate dips, experience has taught me that much already.
If my frame rate was as high as 300fps, but dipped to 100fps in the most extreme situations, it wouldn't matter for me as it would still remain unnoticeable during normal gameplay, not with how G-Sync works as it aims to eliminate perceptible stuttering by making sure your monitor refresh rate matches the frame rate being fed to the monitor, a dynamic refresh rate if you will, 1 refresh = 1 frame, and nobody considers 100fps to be a bad frame rate either.
But despite upgrading my PC build from an older one which had a much slower CPU than my current one, I am still getting dips to around 50fps or less when around my base that has hundreds of chests in it, in the worst case scenario, even with very few apps running in the background, I've caught it going as low as 24fps, where the stuttering does become very noticeable. When this happens in the vanilla game, not with modpacks or anything like that, just the official game, even on PC builds with the Ryzen 5, something is very wrong.
And I don't see why I should have to manually overclock my 6 core CPU, risk burning it out just to get a marginal boost in performance.
16 chunks rendering distance setting, still the same issue, while bedrock edition may be more optimized than Java version, it isn't by much anymore,
because I am having to make do with pitiful render distances just as I did back when I played Java edition, just to make the game somewhat playable.