Through a meta analysis of various minecraft versions and a simple test case involving 100 TnT exploding every 4 gameticks there seems to have been a significant decline in the performance of the TnT explosion code starting in version 1.20.3 and continuing to the latest release. This can be seen in the attatched screenshots showing the milliseconds per tick (/50 ms) of the same test case in different versions
Snapshot 24w33a improved the performance slightly however it still remains at least 2x worse than in 1.20.2 which was found the be the last version where explosion code was most performant in the recent update pool.
Savva looked into the code and found 1.20.3 introduced 2 lag causes to explosion code:
calculating the exposure twice for each entity, but it is already fixed as stated in MC-272414 and after looking at code and testing in game we can verify that this specific issue is indeed fixed.
something within the block removal logic (its
interactWithBlocksmethod inServerExplosion.java). We're not sure that there is only one lag causer within, but we can verify that the lag comes from somewhere there, as it is the only part of explosion code which changed significantly from 1.20.2 to 24w33a
To verify that the issue lies within the block removal, one can use the same setup as shown in the screenshots above, but with a liquid source where the explosions happen, that way each explosion will collect no block positions for blocks to be exploded, thus skipping almost the entire block removal part of the explosion but not the other parts of the explosion, and indeed from our testing there is no lag difference in between 1.20.2 and 24w34a with water present.
Yet without water the lag difference between versions is about x1.5
100 TnT explosions is a relatively moderate amount in the average players gameplay environment. As shown in older versions such as 1.19.4 and 1.20.2 this amount of TnT would only consume half of the computation time for my particular machine that is possibly better than what most players could afford.
Proliferation of Minecraft's code without consideration for the impacts on performance threatens to push newer players on lower end systems out of the Minecraft community and so these optimization issues should be taken with great concern.
Linked issues
Attachments
Comments 5
You shouldn't allocate more than 2/4 gigs of ram when you don't need it. This actually drops the performance due to the garbage collector and other things getting less efficient. 16 gb is severely overkill
Ram allocation is completely beside the point as the environment is the same for each test which shows a clear difference in the lag experienced in 1.20.2 and 1.20.3. As a matter of fact I use a mod which optimizes RAM allocation during gameplay which is not present in the tests to preseve the vanilla behaviour.
1.20.3 introduced 2 lag causes to explosion code:
calculating the exposure twice for each entity, but it is already fixed as stated in MC-272414 and after looking at code and testing in game i can verify that this specific issue is indeed fixed.
something within the block removal logic (its
interactWithBlocksmethod inServerExplosion.java). Im not sure that there is only one lag causer within, but i can verify that the lag comes from somewhere there, as it is the only part of explosion code which changed significantly from 1.20.2 to 24w33a
To verify that the issue lies within the block removal, one can use the same setup as shown in the screenshots above, but with a liquid source where the explosions happen, that way each explosion will collect no block positions for blocks to be exploded, thus skipping almost the entire block removal part of the explosion but not the other parts of the explosion, and indeed from my testing there is no lag difference in between 1.20.2 and 24w34a with water present.
Yet without water the lag difference between versions is about x1.5
i hope someone can post a propper code analisys of the block removal part of the explosion, if noone does ill do it later
Can confirm 24w35a