Crossing certain boundaries within the world causes extreme framerate drops due to a large increase in processing lighting updates (in root.tick.level.connection). These boundaries are only somewhat stable - they appear to slowly shift.
While in the laggy area, the console also prints out the following lines repeatedly:
Client> Something's taking too long! 'root.tick.level.connection' took aprox 157.771458 ms
Client> Something's taking too long! 'root.tick.level' took aprox 158.068499 ms
Client> Something's taking too long! 'root.tick' took aprox 160.314884 ms
Client> Something's taking too long! 'root' took aprox 179.483465 ms
A world in which this occurs is attached, with markers along the ground for the general area in which it occurs. It does not appear to be affected by the Y coordinate of the player at all.
Edit: It might be related to chunks at the horizon, since the lag does not occur upon first loading the world within the lag zone, but changing the render distance does not change where the lag zone is, so I'm not sure.
Edit 2: I've attached several debug forced crash reports (in one zip), some from inside the lag zone and some from outside. The only factor that seems to be changing is the Vec3D pool size, and indeed, the time that it was the highest was also the time that the lag was the worst. Perhaps related, could be coincidental.
Edit 3: It appears that aggressive removal of the map's redstone circuitry (using some not-so-controlled detonation) may fix the issue. I'll bisect the circuitry to find out what's causing the lag.
Edit 4: The lag no longer occurs if I disable some redstone clocks. These clocks are along a chunk boundary. I believe that the lag occurs because as the clock is running, it continues to partially load the chunk, but the subsequent lighting updates from the redstone torch cause issues in this halfway-loaded chunk (I'm not familiar with the specifics of chunk loading for redstone updates, so I can't say for certain).
Attachments
Comments 18
I believe I'm experiencing this bug as well. Got various redstone clocks in my map. This is a very jarring issue indeed.
I uploaded my world (R&D.zip). Some places where the stutter/FPS drop seems to happen most frequently:
Around the water pool:
X = 220
Y = 20
Z = -420
Around the crane:
X = 100
Y = 20
Z = -420
I have clocks at these locations:
foo | bar | qux |
|---|---|---|
X = 227 | X = 188 | X = 246 |
Y = 7 | Y = 15 | Y = 23 |
Z = -355 | Z = -590 | Z = -372 |
X = 227 | X = 171 | X = 193 |
Y = 7 | Y = 15 | Y = 5 |
Z = -364 | Z = -590 | Z = -360 |
I apparently have the same problem with a redstone clock including many torches. They are several chunks away, above level 200. But if I turn them off, the lags are gone, whereas, when I keep the clock running, entering and walking around in the chunk in the screenshot massive and reproduceable lags occur and the cpu usage of process "root.tick.level.connection.checkLight.checkedPosition < toCheckCount" increases heavily.
64bit Win7, Java 7.
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
i think this is a duplicate of MC-36883
Is this still a concern in the current Minecraft version 1.8.1 Prerelease 3 / Launcher version 1.5.3 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
It's worth noting that the only two other bug reports showing up for a search for root.tick.level.connection are MC-11571, which is about a one-time issue on block breaking rather than a continuous lag problem, and MC-12799, which does not provide enough information to conclude whether or not it is the same issue as this or not. I rather think that it isn't, because this particular bug occurs only along a fairly narrow "corridor" of sorts, rather than in a larger general region as MC-12799 describes.