Updating blocks creates lag spikes proportional to geometry in chunk section

Looking at the video, MC-123263 might be related

This example might lead to a fix, or at least a better understanding: https://www.dropbox.com/s/74qnxaqpghh9uxr/Chunk%20Lag.mp4?dl=0

［Ｍｏｄ] Ｍｉｃｈａｅｌ, i'm going to check if the same "Client thread/WARN" happen aswell...

I confirm, this is issue is 100% related to this one. See below what the Log-Output was writing:

16:48:06 wj Client thread warn Something's taking too long! 'root.tick' took aprox 139.149578 ms
16:48:06 wj Client thread warn Something's taking too long! 'root' took aprox 185.002342 ms
16:48:06 wj Client thread warn Something's taking too long! 'root.tick' took aprox 122.662909 ms
16:48:06 wj Client thread warn Something's taking too long! 'root' took aprox 166.025208

Note: I noticed when the pie sort of " over load" it will only show the following:
ｔｈｅ ＂ Ｌｅｖｅｌ＂ ｉｓ ｓｕｐｐｏｓｅ ｔｏ ｂｅ ｔｈｅ Ｒｅｎｄｅｒ
-Level: ８５，００％ ５８．５０％
gui: 15% 10%
unspecified: 0.36% 0,24%

Ｃｏｎｆｉｒｍｅｄ， １８ｗ０９ａ
My issue report is related to this one, and i'll update it when i check. I'll not confirm for further version.

Affects 18w11a.

I think this occurs not when there are blocks "listening for block changes", but instead when there is a reasonable amount of geometry in the chunk. I've attached

, which has examples set up to reproduce the lag. World may take a few moments to load up.

I am not sure if it is related to this bug, but I dicovered another problem with filling blocks:
I wrote a command function that fills large areas. When I activate it the (singleplayer) server can't keep up and the FPS drop. After a while this happens:
Keep in mind: I was playing in singleplayer!

@Marcono1234 can you update the affects version / can you test if this is fixed in 18w22a? Because there are;

• Performance improvements

in changelog.

Affects 1.13-pre1

Hello,

I have the same performance problem with changing blocks.
I created this changing wool game^^

(Picture "lag spikes" above in the attachments)

I can't play Minecraft 1.13 snapshots/pre-releases because the game is very laggy. Hopefully will be fixed before the 1.13 release. 

Yeah, this is a huge issue, it's gotta be fixed. Really grinding everything to a standstill. Everything from cloning to simply placing and breaking blocks takes a toll on the entire game, which it really shouldn't.

This should be a ton more performant now (pre2)

eg. the lag when updating complex chunks with lots of fences or similar

@@unknown, yes my game is now more faster. 

1.13-pre1: 10-15 FPS

1.13-pre2: 20-35 FPS

But is need to test this bug if it is fixed.

Still having heavy lag using sponges with water, most likely due to this. While performance is greatly improved in this prerelease, there is still much to do to fix this performance issue.

It's a little better, but still pretty rough. And using any redstone contraptions (or other things that result in multiple block updates, like Sponge usage) in even semi-complex areas can completely kill my FPS with a GTX 1060 and i7-7700 to a range of 5-10 FPS

i dont know if its the same issue but it happens to me when i break wheat, or any crops or break blocks fast(like with ef v or haste II) and with my melon/pumkin farm the same, it uses pistons and redstone and when they activate one of the files my fps drops from 200 to like 20-30fps, big lag spikes.(on 1.13 prelease 2)

The lag from this bug is definitely not as bad in 1.13pre-2 but still not as good as it was in 1.12.

The lag from redstone or water related blocks is a bit separate from chunks with complex geometry (eg. fences). We might want to split those out into a separate bug.

Done: MC-131549

I did some profiling with pre2, which doesn't seem to be as bad as pre1 (or it's better on Linux than Mac). Honest profiler says these are the worst offenders:

{{ (t 17.0,s 17.0) AGCT::Unknown Java[ERR=-5]
(t 15.9,s 15.9) AGCT::Unknown not Java[ERR=-3]
(t 17.4,s 4.4) bbv::a_}}

Apparently, "AGCT is a mapping between instruction/frame/stack pointer and a call trace." Next I tried OProfile with a plugin that supported Java JIT compiled code, and here's what I got from that:

{{samples % image name symbol name
132730 17.8221 17370.jo boh bbv.a_(ei)
131796 17.6967 17370.jo int bbv.b(bbs, ei)
81707 10.9711 libjvm.so /opt/icedtea-bin-3.8.0/jre/lib/amd64/server/libjvm.so
38688 5.1948 17370.jo void cxc$b.a(bbp, boh, ei, eo, float[], java.util.BitSet)}}

Not sure what bbv maps to, but that seems to be the dominant CPU user for the JVM running Minecraft in single player mode.

They both agree that bbv.a_ is the heavy CPU user. Here's the hot stack trace:

{{ (t 100.0,s 15.3) java.lang.Thread::run
(t 84.7,s 0.0) czb::run
(t 84.7,s 0.0) czb::a
(t 84.7,s 0.0) czf::b
(t 84.7,s 0.0) cxa::a
(t 84.7,s 0.0) cxc::a
(t 84.7,s 0.0) cxc::b
(t 84.7,s 0.0) cxc::a
(t 61.9,s 4.5) cxc$b::a
(t 32.4,s 0.6) boh::a
(t 31.8,s 0.0) bfy::a
(t 31.8,s 0.0) bbv::b
(t 31.8,s 2.8) bbv::b
(t 12.5,s 3.4) bbv::a_
(t 8.5,s 0.6) bqo::a_
(t 5.7,s 1.1) bqo::a
(t 4.0,s 1.7) bqp::a
(t 2.3,s 0.0) bqv::a
(t 1.7,s 1.1) bqv::a
(t 0.6,s 0.6) bqq::a}}

Hopefully this isn't a red herring.

Talking to some friends, it looks like bbv.a_ might be ChunkCache.getBlockState() (MCP mappings).

I noticed in 1.12.x that getBlockState (in World, Chunk, and ChunkCache) accounted for substantial amount of CPU overhead. I developed a block state cache (write-through direct-mapped cache using a specially tuned hash to map from coordinates to cache entries), which made a HUGE difference. That plus a BlockPos neighbor cache literally doubled Minecraft performance for the test cases we tried. The laggiest one was TT's jungle tree farm. In Vanilla 1.12.2, it starts out at about 18TPS, although after some JIT-ing, it rises to about 35TPS (based on the reciprocal of the time spend not sleeping between ticks). These caches increase it to about 70TPS.

In 1.13, I knew that getBlockState was going to get more expensive, at lease because of the extra liquid layer, but I had my concerns about block numbers being fully abstracted (the flattening and all that). This was a performance problem for 1.12.x. It's going to be really serious in 1.13.

@@unknown, The reason I thought redstone/water might be part of this is because of the following:

1. Open a super flat world

2. Build a basic redstone clock

3. -notice no lag

4. Place a ton of fences

5. -notice severe lag

If the redstone lag does deserve a separate bug report, I think the above information is useful to know as the redstone lag is also proportional to nearby geometry... though you may know this already

Thanks. We will look into it!

Hi, Rikard,

First, I want to I express my deepest gratitude for your openness and friendliness towards the Minecraft user community. So please forgive me if I am overstepping any bounds, particularly with respect to the proper use of the Mojira comments section. If you wish to discuss this further in another forum, others at Mojang can provide my contact info.

You mentioned redstone wire, and this is something I know about, so I thought I'd mention a few things. Redstone wire makes heavy use of getBlockState too, so caching block states helps A LOT, but those are only linear-factor speedups. There are bigger problems with the way redstone wire is implemented. See MC-11193 and MC-81098 and my final comment on the latter.

I developed a non-invasive "bolt-on supercharger" for redstone wire that speeds it up by 10x (in our test cases; in terms of computational complexity, it's better than a linear speedup), makes it behave more intuitively, and removes the nondeterminism affected by location and orientation. Grum gave me some stringent requirements for this enhancement to be "acceptable," and I met them all. It has also developed some popularity among the "vanilla plus" modders. I understand that there are some Microsoft policies that inhibit use of outside code, but maybe we can get around that with an appropriately-worded contract and/or NDA that lets me or someone at Mojang port it to the internal codebase and coding style. (I am only interested in making Minecraft better and will freely, no-strings-attached hand over legal rights for this code to Mojang.)

That all being said, redstone wire performance is "merely" a performance problem. There are much more serious data loss bugs like MC-119971, MC-108469, and MC-2025 that maybe should have higher priority, all of which have community-provided fixes.

Thanks you again for your time, patience, care, and enthusiasm!

No problem at all! I'll dig through various redstone things (including your suggestions). Not sure which parts or how much we dare fit into this release though (just a heads up on that).

If the redstone lag does deserve a separate bug report, I think the above information is useful to know as the redstone lag is also proportional to nearby geometry... though you may know this already

I think MC-126518 already covers the redstone lag as a separate bug report. The description of "lag is increased depending on the geometry inside the chunk section" matches that bug report well (see examples).

This bug affects the hopper, stairs all that has a complex shape.

When you create too much, it becomes unplayable very quickly.
when one starts to make a medieval village with system complex redstone in the house,
lag spikes are permanent.

(it affects the pre-release 3).
It should be an urgency to fix this bug.

I checked with MCP the code of the game to understand the issue and to try and fix it, but it seems like mojang will need to completely change the way they render block, since almost every block rendering related function uses chunks and therefore update the whole chunk instead of only updating concerned blocks

Hope this help understanding the issue !

This bug wich has been mostly reported by the youtuber community, affects builds and redstone mecanic. It is truly a dommageable bug.

Seems to have become better in pre4, at least in my testing. It's not quite right yet, but it feels Mojang is slowly getting there.

Hello @ @unknown , I guess your time is precious, so I'll try to make it fast.

I am a developer on a french server with many players connected (1k simultaneously).

And sometimes we have a problems, because some users use this bug, so that the client of others users lag.

If you will more element a Youtubeur have create an explanatory of the bug ( https://youtu.be/dSD4alSCP3E?t=4m20s ) (this video is recent and his turn in 1.13-pre3) And this exemple is equaly possible with Stairs or Hopper.

And I think is not Redstone, it's juste an aggravating factor for me of the problem, the main problem here is in my opinion the method of render when the chunk is updated, is not necessary to update the all chunk when a block,is place, the surrounding blocks is enough.

Wishing you a good end of the day,

Ant74

Still an issue in 1.13 pre6.

Still an issue in 1.13 pre7.

Still an issue in 1.13-pre8.

Still in pre9..

Still an issue in 1.13-pre10.

Still an issue in 1.13.

nope, from my perspective, It's FIXED!

Still seems to be happening.

Confirmed for 18w50a.

Confirmed, 19w07a, 19w08a, 19w08b.

This happens with bamboo too (MC-144465), so if there's a lot of bamboo growing in a chunk then the game can run REALLY slow.  What's interesting is, if you're within a certain radius then you'll get the lag, whereas if you're just outside of that radius then you can watch the bamboo grow all day long with absolutely no lag.  Is the chunk update code in the player's main thread if he or she is in or close to a chunk, and the chunks located away from the player are handled on a separate thread?  This is sort of like how crops used to behave, but now harvesting crops is no longer a laggy experience.

Confirmed for 1.14 Pre-Release 3

Confirmed for 1.14 Pre-Release 5

It's terrible with even a basic redstone clock.

@Jay Eff, correct, chunks within a certain radius of the player (2-3 chunks, iirc) are always run on the main thread, and other chunks run off-thread.

Affects 1.14

This bug is absolutely the worst. Just made a simple two piston contraption using an observer clock near my house and if I stay 3 chunks near it fps instantly drops near absolute zero. I hope they'll fix this soon

I'll add that any redstone/block changes in the affected area also causes it. So redstone dust, repeaters, pistons, etc. It's pretty unplayable with any sort of fast redstone clock

Has Mojang ever said anything about their position on this bug? It has been in the game for more than a year and I'd go as far as to say that this is the most critical bug to fix right now , and one of the reasons why alot of people are still playing 1.12

This comment isn't necessary, but this issue exists in 1.8 as well, it just isn't as easy to replicate; filling a chunk section with fences produces the same effect as in 1.13 and 1.14 in that version too.

This issue can be reproduced after using the /fill command. I did this numerous times and most of the time, this bug happens. You can stop this issue temporarily by reloading the world. Although, this isn't always the case.

This happened when I was working on a Hogwarts Project (see my profile on PMC for details, Username: DieselDorky 16).

This should be a really high priority bug fix, since it pretty much makes building on servers impossible.

Confirmed for 1.14.1

This issue persists in 1.14.2 Pre-Release 2.

Definitely needs a fix asap, anything moving with redstone drops fps to unplayable levels.

Affects 1.14.2-pre3

Affects 1.14.2-pre4

Confirmed in 1.14+

It's still going in the latest patch.

Discussion for all reports on Mojira related to Performance Errors.

Now I am not sure if this is the same issue I'm having on my world, but It seems so. Here's the world download:

http://craftera.com.br/downloads/worlds/season1/29.05.2019_1.14.2_after_chunk_update.zip

Teleport to X: -500, Y: 70, Z: 1800.

This is my base on my server and it was this lagged since server creation on 1.14 pre-releases. FPS there is much lower than anywhere else on the server - on my computer a least. If I turn on the bamboo 0-tick farm it becomes basically unplayable FPS-wise and the main problem always has been breaking blocks as there's a minor freeze in the game (at least for me).

Other members complained about lag in the beginning but I never payed much attention. Now I am as this is tiring me out.

I hope the world download adds to the issue. Thanks in advance!

Confirming 1.14.4 HORIBLE LAG when breaking blocks.
If i get beacon haste 2 effect its so bad omg.

Also can confirm in 1.14.4

Adding video for more information about this isusue with proofs for 1.14.4
https://youtu.be/liO-4nY8q9Y

Can confirm in 1.14.4. Massive lag spikes while destroying trees, especially in the jungle

We have the same problem in 1.14.4 on a minecraft server,

When we place blocks on certains chunks, a huge lagspikes appears on the FPS monitor and the game freezes a bit.

Makes the game unplayable on lower-end PCS, especially laptops that use an AMD CPU.

AMD != Slow
Old == slow
Currently AMD is faster and less power hungry for price vs intel

Optifine reduces the lag by a huge amount
from 0-1fps to a playable 30fps (with a render lag machine)

]

I'm having this problem in the latest snapshot. Here I am breaking grass. The spikes correspond to each grass block broken.

I think this lag spike is related to MC-133877
Biome blend option is causing massive frame drops, if over 5x5. Still there with lower settings, but less noticable. off eliminates the spikes, but looks ugly between biomes.

For a quicker way to reproduce, use the seed -3212589576792698545 and teleport to 256 64 58, then click the door infront of you to get a gargantuan FPS drop.

This is most notable in the new snapshot

That is true. In 19w40a, the game sometimes lags so much it's unplayable because every single time a block updates near the player, the client freezes for a whole second. This makes crops, kelp, and even clicking a mere button extremely resource intensive, and it makes many places in the game inaccessible due to horrendous lag.

Edit: this was at least partially fixed in 19w45a, and the performance actually seems to be better than it was in 1.14.4, but there is still a little bit of lag.

I don't know If someone can still reproduce this bug in 19w45a because for me there are less lag.

If you place torches or create fire with flint and steal it is still an issue in 19w45a. You can easily reproduce by pressing alt+f3 to see the lag meter and f3+g to see the chunk borders and then place a block to near a chunk border. You will see that placing a block near a chunk border is much slower.

Ok

Its not fixed in 19w45a
but the amount of lag has been reduced

Affects 1.15-pre 1. Place light sources and you will see the problem by enabling alt+f3.

Affects 1.15-pre 2 IMHO. Played on multiplayer server, traversed about 200 blocks to spawn camp, it had pretty much clean terrain with a micro farm, mine with stairs and portal and minor grief.

This bug was noticed during the night while removing grief, standing on flat surface with few torches, placing random blocks at ground level created almost 50 ms draw spikes (very noticable when moving), blocks were placed away from chunk borders. Was unable to reproduce after restart, but torch spikes varied from okayish to ~40ms in extreme cases even after restart.

Win7 / Intel HD2500 / Fast Preset / Mipmaps Off

There is an interesting thing that I discovered in the latest prerelease. When you placing a block normally in the world you won't experiencing lag spikes but after blowing up the area and then breaking or placing a block you will get lag.

Video: https://drive.google.com/open?id=1pMCr0tfCBlisuOr6U6mpHko791Czc5jt

Anyone experienced the issue what I showed on the video?

Yeah I think so. Up until like, Friday my mc worked properly, but now it's been hit with this bug

I am also getting this bug in 1.15 main version. Breaking / placing a block causes a lag spike.

edit: It only seems to happen after an explosion e.g. a creeper explosion. Restarting MC seems to fix it. Not the best tho :/

Tested in 1.15.1, still getting frame time spikes

Is the bug in 20w07a

Followed a bug about performance issues in jungles to here. Currently playing 15.2 (I am feeding my game 12GB of RAM as well), the game crashed. Also, I am trying to break the leaf blocks and all I am getting is oak sapplings (wtf?

Here is a test between 1.15.2 Vanilla and 1.15.2 Fabric + Sodium

Vanilla's base ms is higher than Sodium's lag spikes

Sodium is still in heavy development and has not been released fully to the public yet

I think I may have found a potential fix. I set my pc off of "power saving mode" and into "performance mode" and the problem went away.

This is still an issue in 20w18a

Affects 1.16 pre release 2

Can confirm for 1.16 Pre-3

Can confirm 1.16 pre release 4

Affects 1.16 pre release 5

Can confirm for 1.16 pre release 7

Can confirm for 1.16.1

still happens in 20w27a

I'm not sure if this was related, but while I was farming cane in Hypixel Skyblock I was experiencing lag as far down as 10fps, I play in 1.16.4 and I don't see any youtubers (who play in 1.8) experience this, but it's not just my pc, I average 150 fps, so this is an issue and is very annoying

people say it's just the particles, but I doubt it

That's probably not related, seeing as this is client-side lag coming from the game renderer, while what you experienced as likely server-side.

Can confirm in 21w05b.

Can confirm in 21w06a.

Can confirm in 21w07a

Can confirm in 21w10a

I dont know if it is helpful, but i can confirm this glitch.

I always see it when breaking and placing blocks. Such actions can lead to an fps drop with sometimes more then 15fps.

It is easy to see in the alt-f3 menu. It also seems to get worse every update. I hope the new rendering engine can help the devs fix these issues!

has anyone found a solution?
it is necessary to convey to the main developers this problem of the gameplay.

That's not helpful, of course they know. It's not at all a simple problem, the client has to regenerate chunk meshes whenever there's a block update, there's no real way around it. Probably naive but I'd be curious to see a profile comparaison between the current meshing algo and something like this, or to have the mesh update on a seperate thread if that's not already the case.

Can confirm for 21w20a.

Can confirm for 1.17

Can confirm in 1.17.1 Pre-release 1.

This is a picture of the alt-F3 menu showing the impact of placing and breaking wooden planks.
This picture is made in 1.17, on a server with the following Video Settings:
Graphics Fabulous!
Biome blend 5x5 (normal)
Max framerate: unlimited
Render distance: 10 chunks
Vsync: Off

Specs:
Windows 10 Pro N
CPU: Amd ryzen 2600
GPU: Geforce GTX 1050ti
16gb ram, 4gb allocated to minecraft

Server is running with 10gb ram

Can confirm in 1.17.1 Release Candidate 2. Can be reproduced with sponges draining large amounts of water.

Still a problem with setting priority updates: nearby in 21w39a.

Can confirm in 21w43a.

Can confirm in 1.18 Pre-release 2.

Can confirm in 1.19.3

Can confirm in 1.19.4

Affects 1.21

Using: ( "GCTimeRatio": 0, 
  "ao": false, 
  "spriteAtlasTextures": false ) Patches the issue, would prefer a more optimal solution.

incorrect version tag stating 1.21, it stops at 1.20.2 mostly.

Affects 1.21.4.