Chunk loading/generation is significantly slower than 1.13.2

Can confirm, whenever we switch dimensions on my server (whether I'm local or my family 800 miles away does it) whether I go through the portal or do an in_nether execute tp command, it will put you there, but will take forever to load, meanwhile if someone else is there they can see you and you can be killed by mobs, your debug screen will still say waiting for chunks..and oddly enough, the weather in the nether waiting area seems to be rain(when overworld is raining)...also effects 18w46a, whether server or lan hosting. Also update, effects both mac and windows...so just java version overall most likely

I really hope they fix this soon. It makes the game pretty much entirely unplayable.

Still occurring with 18w46a in fact it is a bit worse than previous snapshots
(This is not just on integrated servers but also on dedicated)

I'm getting this bug 100% reliably on Linux, maybe it should be added to the Environment field. cf my duplicate MC-139482

i'm playing singleplayer, suspect it's related to world size (also I noticed it's now "preparing spawn area" every time the world is opened, so if it's regenerating the entire world??? maybe that's related)

here is a manual crash report if its good for anything - captured while waiting for terrain to load

Can confirm for 18w46a on dedicated Server. World is not loading when you respawn, or you have to wait for 1 minute for the world to load, and sometimes players joining game simply causes the server to crash upon exceeding max tick delay, especially happening the more the player is away from 0 ~ 0 (set as the spawnpoint), even if the chunks are already generated.
This is also especially the case when going to the Nether, game is first stuck on "loading terrain", then you spawn on an empty world and have to wait untill the world finally loads for you, or the server crashes upon exceeded tick delay.

Also since 18w46a, there is a new loading issue I didn't encounter before: sometimes when moving, either the chunks aren't loading or only some chunks fail to load while the others around succeeds at loading (see the screenshot I added). Restarting the server solves this issue. When happening, client logs spamming "Ignoring chunk since it's not in the view range", and the second value of the MultiplayerChunkCache is dropping (also the second value is never equal to the first one).

I just reproduced it in 18w47a (Linux, 16GB ram, i5, SSD), both in a new world and in a world from previous snapshots.

World generation for me is so slow to the point where I get rubberbanding to occur with everything, I cannot break anything easily as it takes an obsurd amount of time to drop its item. My PC is high end so I know this isn't windows causing this.

I don't know if this helps any but I noticed a slight performance improvement upon moving my save to a Solid State Drive (SSD), still lags though.

@Cody Fenno that’s pretty much a guarantee. I’ve been running my server on an SSD the whole time, and I only get <10t/s on a good day.

Forced a crash after running for 4000 blocks distance after lag spike of death.

Confirmed for 18w47b. I created a new world and waited 5+ mins, but the world wouldn't load until I hit esc. They have said on the Minecraft website "Numerous worldgen performance improvements", which I find to be subtle.

Edit: I also did /locate Village to see how well the world would generate from teleporting, however to little surprise the world was loading extremely slowly, even when hitting esc.
(I know my laptop sucks however in previous versions of the game it could still load the world at a reasonable pace)

18w47b has fixed the lag issues I was having on my MSI GE72 6QF Apache Pro, but I'm beginning to see why the performance was so poor, I think it has to do with the compatibility with whatever computer we have as well as what's already installed and if it's been optimized. We should probably post our PC specs as we look deeper into this. Maybe it will help Mojang understand what kind of PCs are affected.

18w47b is a little better for me, but still very slow when you compare it with the last non-snapshot release.

The "1 minute to see a first chunk" issue seems to be largely fixed, but loading and worldgen is still painfully slow.

Running on a server, 18w47b is infinitely worse than 18w47a; the world just never actually loads at all. No crash or anything, and the server only compains about running about 40 ticks behind every 20 seconds or so. The client simply never loads the chunks.

Contrary to @cjburkey01 on my machine (an elderly MacPro) 18w47b runs better than 18w47a, which was nearly unplayable, it lagged so bad, and not only on chunk loading.  But there are still serious chunk loading problems now, and glitches that seem induced by lag (I fell off a tall column when mining straight down – I saw myself glitch to the edge without having moved of my own accord, and then I fell off when I next hit the block with my pick).  Upon first entering my test world I still hang in a void for nearly a minute (see only the sky and what's in my hands, no terrain).  FWIW 18w44a ran best for me out of the current snapshots.

Is this an issue with the server sending the chunk info to the client or an issue with the client rendering the chunks?

I have 16GB or Ram allocated to the snapshot server with an average of 1 or 2 players online at a time. Disabling my datapack did nothing to help the issue. The server was unplayable in 18w47a as it would crash but now in 18w47b chunks are either slow to load or do not load at all.

Im running a HP DL360 G6

they can do it like in 1.7 when performance was the smoothest

@Matej Mráz they can't just "do it like they did back then." They rewrote the entire terrain generation system in 1.13 when they rewrote the game, and have been working more on it in 1.14.

@Michael Hurt Wait, I've got an Intel Xeon X5670 (6-core, 2 processors), but used to have Xeon X5550 (4-core, 2 processors); the chunk issues occurred on both systems. Is this an Intel Xeon issue? I was running Windows 7 Home Premium on the system and 10 gigabytes of ram allocated to the server.

Have this or similar issue as well on 18w47b and earlier versions. 

At first, some chunks don't generate and player can get caught in unloaded chunks hanging them.   If you get caught in an unloaded chunk it doesn't ever load, and stays on "Waiting for chunk..." in the F3 screen.

Rebooting the client, the chunks might load.  But after a while other chunks will not load. And once you are in an unloaded chunk, getting out of it might only be possible if you are on the edge of a loaded chunk and in creative as slow movement is possible.  F3+A on the client will not reload the chunk.

Once in an unloaded chunk, you can hear noises of entities near by and sometimes see some details in neighboring chunks, which leads me to believe that chunk or lighting updates are never received by the client nor resent because of the issue, but other packets are. For example, interacting with items like food is problematic, but works if you keep clicking for a while.    

Over time running the server, has gotten to a point where loading the client spawns you in a world that doesn't load the chunks visually.  When I connected in this unloaded chunk state, the server was constantly behind in ticks, on the order of 300+.  Perhaps it's backed up somehow on sending a chunk or lighting update and never recovers. 

The server doesn't seem to be overloaded from a hardware perspective.  The server is not taxed, and there is ample disk space.   Client side FPS is normal, even better with no chunk data.    

Rebooting the server, I was sometimes able to get nearby chunks to load.  And able to get out of the unloaded chunks on connect problem.  So the issue builds over time and is mainly server side.

Also, since client side performance is good, I do not think it's an issue on the client. Looks like the client just never gets some chunks.

Just a follow up, seems that the chunks are not loaded on the client side (C values in debug are very low looking at unloaded chunks), but exists on the server side as entities exist in these chunks.  Leads me to believe that the chunks are generated, but something is interfering with them being sent to the client side properly.

Also, this is pretty much only happening in multiplayer.  Single player, I'm not seeing this issue.

@klugemonkey: This is definitely also affecting singleplayer.

I've noted weird phantom lava and water in unloaded chunks. It kills fps, which kills cpu on my macbook.

@unknown, that's MC-138108.

Still occurring with 18w48a

Yup, chunks still simply don't load on the client when joining a server, though the server is running at about 13-15 t/s (It's been slow since the snapshots started, so that's "normal").

Actually, after about 15 minutes of sitting in the void, suddenly half of the world loaded, still waiting on the other half. Update: the world loaded after 17 minutes!

"Significally slower" is a huge understatement for my case.
I downright can't play Minecraft, neither multiplayer nor singleplayer.

Whenever I enter "the world", I look at nothingness. I only ever see the sky, nothing happens no matter how long I wait (tbh, I didn't bother waiting more than 5 actual minutes).

I can open my inventory, but I never see anything of the world. Eventually, Zombies are going to eat me, and when I respawn I'm back staring at nothing. F3 is saying "waiting for chunk", but it's waiting forever.

This also occurs when I just go into singleplayer and create a new world with no settings changed whatsoever. So it has nothing to do with the world, but seems to be a strictly technical issue.

@Patrick Dinklage What processor would you happen to have? If you tried multiplayer, do you know the server specs?

For me on my own on a SMP world made in 18w48a It takes a bit for terrain to generate, with 4+ players it just dosent happen or takes literal 2+ minutes for Terrain to start appearing.

Im running an AMD - Ryzen 7 1700 3 GHz, 32GB DDR4 RAM with a GTX 1080

Server is running Ubuntu 18.04.1 LTS
Intel® Core i7-6700
64 GB RAM
2 x 500 GB 6Gb/s SSDs

@CJ Burkey
Server has 2x Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz. That's hardly the limiting factor here, especially since this issue never occured before the 1.14 snapshots.

My notebook (client / singleplayer with) runs on an Intel Core i7-5500U @ 2.40 GHz, never experienced any performance problems with Minecraft.

@Patrick Dinklage I was asking because both @Michael Hurt and I had servers with Xeon, at least we know it's not that.

@CJ Burkey
I got a feeling this is faulty networking code, maybe a deadlock where client and server are waiting for each other acknowledging something and it never happens, caused by a race condition possibly. Only a guess.

Cause it sporadically worked for me today - no problems whatsoever. Then I log on a few hours later and no chunks are loading again. Doesn't feel like a hardware related issue.

@Patrick Dinklage It could be something like that, I notice a pretty high RX count (around 500), though that may be low for all I know, I don't pay attention to it usually. I wait about 15 minutes and my world loads, and usually almost all at once, which tells me it wouldn't be computation power at fault.

A thing I noticed experimenting with different world seeds: ocean worlds load significantly faster and smoother than land worlds. Maybe it's just because there's less data to transfer, or the bug is in the land generator.

Example - world seed 4 (ocean with sparse islands), 5 (ocean with icebergs).

vs 6 (ocean with an extreme hills island - see the difference in load speed of the two parts), 7 (large swamp and taiga), 9 (plains, dark wood)

the land worlds load a square around spawn and then stop for a bit, whereas the ocean worlds load in a diagonal fashion and don't stop so quickly. They are also more likely to resume loading when you approach the edge of the loaded area.

maybe this helps with debugging, maybe not. But it seemed like a possible clue

Just a note, I seem to be getting significant improvement after changing my JVM from OpenJDK 10 to Oracle 8 (1.8.0_191) on the server and tweaking several JVM settings. Might be useful to note that its using close to 4G for the server. 

I have been getting the same lag in my singleplayer 404 seed world. It makes looking for the new villages really tedious. I have to keep doing the F3+a trick every 10 seconds just to load in more of it.
I'm using12 chunks render distance, Fast graphics, smooth lighting turned off, biome blurring off, particles set to decreased and some other video settings set to a low-ish range. Hope this helps out with the server and single player client bugs. Good luck!

woops old post had my list oldest on top newest on bottom my bad

I hope they fix this soon. I'm on the most recent snapshot 18w48b and it's so slow. I'm not teleporting or switching dimensions, I'm just wandering on foot and the horizon all around is just empty. When I get closer, I have to wait a few minutes for more world to show up. The game in general is also extremely slow and laggy. The only time this doesn't happen is if I'm digging underground. F3+A doesn't help, it just reloads what I already can see and doesn't seem to speed up the loading of the rest. 

This seems to fit a LOT better than the other chunk loading issues I was directed to, especially walking up to the edge and it not loading for several minutes / flying up and only seeing a very small loaded map / no horizon. Agreed on the results of using f3+a. Sometimes opening the menu screen helps, but not always. Still needs to have the root cause fixed. 

I'm now seeing that the chunk load culling is only happening to my older converted maps. But freshly created worlds for the latest snapshot still have issues with rubberbanding, the loading taking awhile, & blocks disappearing & reappearing after being placed or destroyed.

Also potentially relevant, here is a look at the server processes for the latest release version (mcserver, minecraft_server.jar) and 18w48b (mcserver2, server.jar) in ps on FreeBSD. Both servers are currently idle, no players present, and no redstone devices or other activity going on in spawn. Compare CPU and memory utilization (3rd and 4th columns) between both servers:

USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
mcserver 21418 0.0 1.4 11908688 1392200 0 Is+J 22Oct18 2176:37.89 /usr/local/openjdk8/bin/java -Xmx8G -Xms2G -jar /usr/local/minecraft-server/minecraft_server.jar nogui
mcserver2 66316 101.1 4.9 19780004 4924556 5 Is+J 22:21 6:54.67 /usr/local/openjdk8/bin/java -Xmx16G -Xms2G -jar /usr/local/minecraft-server2/server.jar nogui

This machine has 12 cores/24 threads, and the 18w48b server is basically hogging an entire CPU thread and over 4GB of RAM continuously even while idle, while the release version is barely using a gig and no CPU.

Aye, I can confirm the 18w48b server using a full CPU albeit no players being online. May have to do with this too.

This is a significant issue on my LAN server. The first person can usually log in, and the world will render, but takes several seconds the second person will usually have a long lag (up to a few minutes) then the world will render, but any more, and it will sit there with a blank sky, and/or kick the person off because "flying is not allowed"

Confirmed in 18w49a

Same problem. the client loads the area of chunks around the player during connection usually fine. however leaving this area the chunk loading simply appears to stop. 

Perhaps this is related to https://bugs.mojang.com/browse/MC-118106

@Warren Liddell I don't think so, it's on singleplayer and multiplayer for some people; if it is related to that, it would mean it's the internal server on the client, but it's not occurring for everyone.

The sad thing is that this issue is so critical that it is limiting other useful testing on multiplayer.

@David Chamberlin Definitely; haven't been able to play since 18w43c (there was a 10 minutes or so for one of the snapshots a few weeks ago that I managed to get my friends on, but it was too slow to do anything like leave the spawn chunks)

@@unknown's old comment accurately describes my experience interacting with the unloaded portions / how little of the world loads and how slowly, and I also get "preparing spawn area" every time I open the same worlds.

Believe this could be the same issue as MC-140877 and MC-139717

@Corey Norlander I think MC-139717 is a duplicate unless there's some nuance in the issues.

@David Chamberlin Yeah. SMP Is unplayable right now. Hopefully they fix this soon. 

Yeah, SMP on 18w49a is definitely unplayable.

We've been needing to restart the server every time someone wants to join the game or if teleporting them out of the chunk "void" doesn't work.

I too am having this issue

Still affects the last snapshot of the year. Booo

All the new features are worthless if they never even load up... fix your damn game breaking bugs first, Mojang!

We are still having this issue on the 18w50a snapshot, sadly... Hopefully early next year Dinnerbone (or whomever is working on it, I just saw he was assigned this) will have the fix all ready for this.

If anything, though there has definitely been improvements with this newest snapshot. As I have stated below in the tagged messages. The logging in issues that we were having have pretty much all been remedied, the only issue is that some chunks are refusing to load, but a pretty quick relog tends to fix that.

@MightyPork On our server we seem to be having few, if any, login errors. It's mostly the chunk issues. If the chunks are refusing to load after a minute or two, we just have to relog and it usually fixes it.

@Patrick Dinklage You know this is you complaining about a snapshot right? You could just go back to 1.13 and play that, it would be a lot more stable. No one says you have to play the snapshot / prerelease / beta versions of this game.

Can confirm 18w50a is atleast playable however moving long distances is a great test of patience. 

It seems to be that loading a chunk takes so much of the processor. When being alone with a good computer it is workable. But (depending on computer cpu strength) when more people are joining it get slower. At one server I am on you can just play with 2 persons, but not both running around and loading lot of chunks. On another server it takes a few more persons. And these are servers that previously could hanlde much more activity without any problems. The one where 2 are getting in trouble now, would regularly have minimum 10 online when I was playing and there was no problem with lagging whatsover. So it is very, very heavy on CPU with the new snapshots (every snapshot for 1.14).

And @Thomas Hine, yes we can and do play also on other servers. But I also like to play on snapshot-servers, but it is not really playable, so what is then the use of releasing a new snapshot if we cannot test it to see if it works? This is just one big major issue with the snapshots! It seems to me that although it is 'nice' to have new features and although stuff might not be working (I have waited for weeks to get my greens back in a previous snapshot) and that is allright. It is a snapshot. But not being able to play normal is really hard to explain. Maybe it would be good that Mojang would have a comment on this, that they are indeed having there full resources on this. It now looks that this is not considered a major issue somehow. 

So @Mojang: THIS IS A MAJOR ISSUE! pfff... hope they see this red flag 😉

@Thomas Hine I am running a snapshot server, both playing and testing new features at the same time. This is in Mojang's interest. Testing new features, however, isn't possible if not even the basics are working. So it's also in Mojang's very best interest to fix these game breaking things first before adding more and more new things. That just doesn't make any sense.

i agree, snapshots are a very valuable technique to get people to try out the new stuff and see if they can break something. but if they are not able to try it out because of a major bug, all the new features remain basically untested until this one is fixed. this means the overall times that new features are "out in the wild" before releasing a major version decreases the longer this bug persists.

Currently my server can handle 25-30 users online with 1.13.2 with the snapshots currently what they are im lucky to handle 1/4 of that without running into major issues

It seems as if the new generation method is a heavily single threaded work load. If they can find a way to split the load across the threads it would be significantly faster. 

@Digit1704 It is a major issue. The fact that the newest snapshot is better than the last coupled with the fact this ticket has yet to move past the open stage tells me the chunk gen code is still being actively altered. If my observation is correct they could be intending to finish all the new features and changes to chunk gen/loading before optimizing the code. It would be nice if @Mojang would communicate with us a little better on major bugs like this one though.

It would appear that 18w50a fixes this for me! The debug commands drops the TPS to 2-3 t/s, but when it's not running, the server feels like 17-19 t/s, which is butter compared to the last 17 weeks of agony. I don't think I changed anything else.

@CJ Burkey what debug commands are you talking about? i also recognized an improvement in 18w50a, but after half an hour of playing or so average tick rate went up to 60 seconds again. maybe some kind of cleanup problem? cpu iterates through more blocks than it has to after a while?

Setting my render distance higher than the server's seems to reliably fix this for me.

Can anyone else test this?

I noticed it specifically at 15 chunks locally and 10 server side I reliably get no problems.

At 8 locally and 10 server side I get problems very quick. It's actually so consistent I did several tests where I flew back in forth in creative until there was a problem.

4 local/ 5 server: 15 seconds before chunk error
5 local/ 5 server: 30 seconds before chunk error
6 local/ 5 server: no problems in 10 minutes

If this is a good workaround, until it gets fixed, I'd recommend people set their render distance 1 chunk higher than the server so you benefit somewhat from the chunk fade of the local setting.

As a note, I am running openjdk 11 on all clients and server but I don't think it is related.

Just tested this, Hasami, can confirm.  My server is set to 14 chunks.  If my client is at 15 or higher, everything seems normal.  The moment I set my client chunks to 13 or lower, the world stops loading in all directions.  If I log in with <13, it loads the initial area around me but refuses to load anything more, even if I raise my chunks to 15+ again, a relog is required.

My client and server are both on sun java, as you say I don't think it's related.

I can't confirm any render distance related magic here, just tried setting one higher than the server's view distance and nothing changes. The combination of 10 server / 15 client does neither. Usually, I'm about 10 chunks higher than the server it appears. Seems completely unrelated to me.

I've confirmed this behavior on 4 different setups with pretty different hardware configs. 18w50a, windows 10, openjdk 11

@Patrick Are you relogging between changing the graphical settings locally? Once the chunks are "waiting" there doesn't seem to be a good way to make them come back other than relogging.

Unless you're talking about just general performance issues, in which case... That's probably a compound problem from at least 1.13.

Edit: The problem can appear again after the server and client have been up too long. At the very least, it is an improvement.

How does one set server render distance and/or view the current setting?

@Quinn Dagenais Change the

view-distance

value in server.properties

Is this possible for local worlds?

@Quinn Dagenais Just change your render distance in video settings, that should change it for SP and lan

I don't know how high I need it to be though.

@Quinn Dagenais Peter says he couldn't confirm whether it helped, but you could try 16 to see if the server side of the game runs faster.

Ok thank you. I have been dying to try the snapshots but couldn't stand the lag.

I have a very decent laptop and no matter the render distance I set the game to (in this snapshot), I get the same issues presented here. I can't fly with my Elytra for more than 5 seconds before I have to land and wait for the world to continue to generate. 😛

Yeah I should have commented in the other thread instead. The fix of making sure server side chunk distance is smaller than client is for the chunks never loading bug. The chunks that go "waiting for chunk" when you stand in them.

This bug of things just randomly taking forever to generate or always being last to load when going through a netherportal, etc is probably related but not the same.

This also makes the preformance of the game signifacantly lower, compared to earlier snapshots and 1.3. Its very laggy.

Chunks loading is responsible for mobs duplicating reported in [MC-138919] and [MC-138871]. Setting the chunks on forceloading makes the mobs not duping anymore.

It's still extremely slow in 19w02a

@Supernova792 Honestly I'd say it's worse in this version in the wake of their "performance improvements" for 19w02a.

It's not in the changelog for 19w03B so that needs to get added to this

This wasn't fixed in 19w03B, though it seems like more chunks re-load after unloading.

This issue is still present in 19w03c

19w03c is now playable on servers, though not perfect. Dimension transfer is still slow but other than that it seems improved

 CPU load is still unacceptably high though - snapshot server still keeps one CPU core permanently pegged at 100% when idle, while the other servers only generate negligible load while idling.

Can confirm for 19w04a.

can confirm.

Same here, the chunk loading is horrendous

Today my friend relogged into the server and after that the chunks close to him did not load at all.

He was stuck in the air as shown here: 

The server was not restarted as he didnt have permissions and was the only one online at that time, but multiple relogs didnt help.

After I joined the server and went to his location, the chunks started rendering and he finally could move, but nearby area was still loading visibly slower than other places.

It was at 19w05a

How can there be anything more important than this at this point for whoever is responsible for backend development? Is there even anybody responsible for it?

This bug has been reported over three months ago, received more than 100 votes and almost 100 comments in that short time, it has been confirmed (or at least acknowledged) by Dinnerbone and it renders every snapshot absolutely useless because the game is unplayable in multiplayer (and also in singleplayer due to MC-118106, which I believe is related).

Mojang, get your priorities right and communicate. Are Mojang devs even using this issue tracker to see what the hell is going on? Is there any way to get their attention here so they realize that this is a serious problem (e.g., for the mods)?

Literally game breaking issue, is imposible to play. 

When I enter a world it charges like 8 chunks around me and no more, the next chunks never load.

This issue is specialy stronger in Multiplayer.

@Vicente I was in the same boat as you for a bit however if you read back in the comments you can see the issue is more dramatic when the number of chunks you are loading at anyone time is less than the amount the server has loaded. When I say more dramatic I mean while loading only a few chunks the game is unplayable and at a higher amount of chunks it runs just fine and is playable. Mind you your PC does have to be good enough to render larger amounts of chunks but it does effectively solve the problem. I think the main reason this issue is so bad for some people is because the temporary solution is counter intuitive requiring you to load more chunks client side instead of less.

The generation of new chunks is incredibly slow and generates many lagspikes, on the client side as well as on the server side.
(Example: videos "Lazy chunk loading 1 and 3").

It is the same thing when you want to teleport: horrible lagspikes and chunks that have trouble loading (Example: video "Lazy chunk loading 4").
Note: This applies to both new chunks and already generated chunks.

Plus, mobs appear before the chunks load / generate.
So, some of the mobs die (Example: video "Lazy chunk loading 2" with a suffocating guardian).

Still in 19w07a

For me, I've been having this issue ever since the 1.14 snapshots began and is still present in 19w07a, for my world it seems to be anything outside the spawn chunks rarely ever load. Sometime's I can get them to load up if I stand just at the edge of the loaded chunk and close the world and re-enter, but most of the time I cannot get them to load, which is kinda of frustrating because I've been working on this world for a server of mine in single player, and I have some projects im trying to do just slightly outside the spawn chunks...  the plus side is I've now  memorized where my chunk boarders are.. lol Please fix Mojang.

Edit: And for further info, the world Im working on was generated in 1.12, then upgraded to 1.13 before going into the snapshots.

Edit 2: after getting frustrated for waiting 40mins I started to spam click the "reload chunks" button (F3 + A) and after about like 10 clicks the chunk finally loaded.

Also, pause and unpause the game helps a bit.

Still in 19w08a

Can also confirm for 19w08a, seems to be worsening compared to previous snapshots.

Can confirm in 19w08b

Still in 19w09a

I've noticed this as well.

Still in 19w09a

Here's a code analysis on this bug:

To take away the punch line: The issue is completely client-side. Chunks are loaded properly on the server and sent to the client. The client, however, discards them when they fall outside its view range which leads to multiple problems.

There are two codepaths on the client that throw away chunks when they fall outside the clients view distance.

(1) A filter that discards chunks right away when the chunk packet arrives.

ClientChunkManager.java

@Nullable
public WorldChunk loadChunkFromPacket(World class_1937_1, int int_1, int int_2, PacketByteBuf class_2540_1, CompoundTag class_2487_1, int int_3, boolean boolean_1) {
  this.updateChunkList();
  if (!this.chunks.hasChunk(int_1, int_2)) {
     LOGGER.warn("Ignoring chunk since it's not in the view range: {}, {}", int_1, int_2);
     return null;
  } else {
      ...

(2) A clean-up routine that unloads all chunks outside the clients view radius once per tick (or whenever a new chunk packet arrives).

private void updateChunkList() {
   int int_1 = this.chunks.loadDistance;
  int int_2 = Math.max(2, this.client.options.viewDistance + -2) + 2;
  
  ...

  int int_5 = MathHelper.floor(this.client.player.x) >> 4;
  int int_6 = MathHelper.floor(this.client.player.z) >> 4;
  if (this.playerChunkX != int_5 || this.playerChunkZ != int_6) {
     for(int int_7 = this.playerChunkZ - int_2; int_7 <= this.playerChunkZ + int_2; ++int_7) {
        for(int int_8 = this.playerChunkX - int_2; int_8 <= this.playerChunkX + int_2; ++int_8) {
           if (!isWithinDistance(int_8, int_7, int_5, int_6, int_2)) {
              this.chunks.unload(this.chunks.index(int_8, int_7), (WorldChunk)null);
           }
        }
     }

     this.playerChunkX = int_5;
     this.playerChunkZ = int_6;
  }
}

This causes (at least) three slightly different appearances of the bug.

Appearance 1: ALL chunks outside the login area are missing

When joining a multiplayer server and clientViewDistance < serverViewDistance, no chunks outside the login area are visible. This is caused by the filter codepath. The server will send chunks as soon as the player is less than serverViewDistance chunks away. However, the client will directly discard them if they fall outside clientViewDistance. So, when moving continously (ie. not teleporting) all new chunks will be discarded by the client because its view distance is stricly smaller than that of the server.

The server doesn't know about this and assumes the client knows all chunks it sent. As a result, all of those chunks will be permanently missing on the client until relogging (or moving away far enough, so the server sends them again).

This mismatch of view distances between client and server is the most servere of the three appearances.

Workaround:

As others have noticed, increasing the client view distance helps to counteract the problem. From the analysis, it is clear that you need a view distance of at least serverViewDistance.

Appearance 2: Spawn chunks and chunks loaded by other players are missing

This is a slight variation of Appearance 1, where only spawn chunks and chunks loaded by other players are missing.
One detail that I didn't mention in Appearance 1, is that the server view distance isn't actually what you configure, but it is 1 larger.

The server view distance is basically set as follows:

DedicatedServer.java

public DedicatedPlayerManager(MinecraftDedicatedServer class_3176_1) {
    super(class_3176_1, class_3176_1.getProperties().maxPlayers);
    ServerPropertiesHandler class_3806_1 = class_3176_1.getProperties();
    this.setViewDistance(class_3806_1.viewDistance, class_3806_1.viewDistance - 2);
  ...

... omitting some call levels ....

ThreadedAnvilChunkStorage.java

protected void applyViewDistance(int int_1, int int_2) {
  int int_3 = MathHelper.clamp(int_1 + 1, 3, 33);
  if (int_3 != this.viewDistance) {
     int int_4 = this.viewDistance;
     this.viewDistance= int_3;

Note the additional + 1 in MathHelper.clamp(int_1 + 1, 3, 33). This does not happen for the clientViewDistance.
Hence we should distinguish the chunkTrackingDistance = serverViewDistance + 1 where the latter is what you configure in server.properties.
Because of this, we have Appearance 1 again in disguise. It does not just happen when clientViewDistance < serverViewDistance but actually when clientViewDistance < chunkTrackingDistance.

So, why does clientViewDistance == serverViewDistance help to solve Appearance 1 in some cases?

There's another variable controlling the chunkLoadingDistance. This one is now actually == serverViewDistance (I haven't read that codepath completely to determine the exact value. But from Appearance 1 I conclude that it should be this). Because of this, the effective view distance for not yet loaded chunks is capped by the chunkLoadingDistance, ie. serverViewDistance, and so setting the client view distance to this solves Appearance 1 for all not yet loaded chunks.

However, as soon as you come near a chunk already loaded on the server, e.g. spawn chunks, the effective view distance increases to chunkTrackingDistance == serverViewDistance + 1, because you don't need to load the chunk first, so chunkLoadingDistance is irrelevant. This triggers Appearance 1 again.

Workaround:

As for Appearance 1, increase the clientViewDistance. It now becomes clear that we need to set it to at least serverViewDistance + 1.

Appearance 3: Chunks are missing when "moving too quickly"

This issue is now caused by the clean-up unloading codepath. It can be reliably produced as follows:

• move sufficiently fast until the server teleports you back because you were "moving too quickly", e.g. when moving on a laggy server

• turn around and move back the way you came for some distance

• observe that there are missing chunks

Because of the clean-up unloading path, the client unloads the chunks behind you as soon as they get out of the client's view range. When the player is then teleported back by the server, those chunks will be missing. As before, the server doesn't know the client unloaded them and hence won't send them again.

From the explanation, it gets clear why this only happens for chunks behind you but not for chunks in front of you.

Workaround:

Again, increase the client view distance. As it gets larger, the probability of encountering this issue gets smaller, as you need to be teleported back at least chunkTrackingDistance - clientViewDistance chunks. Note that setting the client view distance higher than serverViewDistance + 1 shouldn't cause any harm, because the server won't send more chunks anyway. Hence I recommend setting it to 32.

Proposed Solution

The client should tell the server its view distance. And the server should take that into account for determining which chunks to send to the client. Whenever the server determines that the client should unload a chunk, it should tell it to do so (this mechanism already exists). The client should never automatically unload any chunks. (As mentioned above, allowing the client to automatically unload chunks results in the server thinking the client has a chunk that it does not have, so the server will never send that chunk again, and this is why some chunks appear to never load.)

The suggestion to have unload controlled by the server is optimal. In particular, this will reduce the bandwidth usage compared to the current algorithm, which still sends chunks that the client just discards. And it should be fairly easy to implement as most of the logic already exists. Basically, one only needs to remove the client side filter and automatic clean-up logic and instead execute unload requests sent by the server.

If you wish to allow the client to automatically unload chunks, things get more complicated. Either the client should tell the server whenever it unloads a chunk, and/or the client should be able to request to receive a chunk even if the server thinks the client already has it. Unfortunately, in this scenario, network lag may still cause client/server desync, similar to Appearance 3. For the most seamless experience, with least bandwidth, chunk unloading desired by client and server should not occur asynchronously to each other.

I really don't see any benefit in the client making unloading decisions, especially since that complicates things alot. So, I strongly recommend to just get rid of this and allow the server to decide which chunks the client should unload, based on the minimum of server view distance and client render distance.

Hope this is info is helpful 🙂

Thanks to @unknown for helping me with testing and writing the report.

Still happens in 19w11a.

Still in 19w11b

bug is still very much a thing in 19w11b

Can confirm, chunk generation works awfully bad on the latest snapshot.

I don't know if it's directly related to this bug or not, but it is also overall laggy on my end. Playing on Single Player feels like playing on a bad quality Multiplayer Server. Loading times in general are quite atrocious, a block takes a few seconds to drop to the floor, getting into the Nether takes a while, and when you reach the Nether it has serious issues loading up, I couldn't even fight a single Zombie Pigman because it got stuck in the air after hitting him once with a Stone Axe.

In comparison, every single thing works perfectly fine with the same configuration and the same JVM arguments on the version 1.12.2 of the game (no mods, not even Optifine).

Blocks fall to the floor instantly after breaking them and going to the Nether doesn't even take a full minute.

Specs: Intel Celeron N2840, Intel HD Graphics, Windows 8.1 (x64).

Config: https://i.imgur.com/kMWIhmI.png

Notes: In the Launcher I have the path to Java SE Runtime Environment 8u201 for 32 Bits set in Java Settings - Executable in both of my profiles (one for the Snapshots and one for Stable Releases).

I also use the following JVM Arguments, again, in both profiles: -Xmx1G -XX:+UseConcMarkSweepGC -XX:-UseAdaptiveSizePolicy -Xmn128M -XX:+UnlockExperimentalVMOptions -XX:ParallelGCThreads=2

Can confirm this as well. All snapshots have been a little slower for me, but since 19w11a it has been intolerable. I've been testing singleplayer exclusively. I noticed when I got in a boat the lag went to unbearable 3-4 second lag as the boat jerked forward the distance of approximately a block. It isn't my video settings or computer - 1.13 runs great at max settings. Since 19w11a I can't run this at lowest video settings with chunk distance turned below 10. I'm not running any mods.

Confirmed in 19w12a.

I just tested with a brand new world and can confirm that this issue was not present when I was the only player. Chunks were almost able to keep up with me flying at maximum spectator mode speed. It gets bad when another player joins and starts loading chunks, at which point the entire server experiences a ton of lag. 19w12a has made this seem a little nicer, though. When only one player is loading new chunks, the server runs tolerably, but definitely not well.

Still in 19w12b

Although I myself don't have this issue, when I host a LAN world with friends who have worse computers, they seem to have issues with chunk loading. They do not have this issue when playing single player. I am in 19w12b

Still in 19w13a

Problem persists for me in 19w13a

Since the symptoms are very similar, I should point out that world generation is broken in 19w13a, causing new chunks not to generate at all. The report for that is MC-146778.

Confirmed to still be an issue in 19w13a. Lowering view distance to 6 no longer helps, and we have to reconnect constantly.

This should only affect spawn chunks: MC-146778.

Brandon, each comment or change on this issue notifies the 117 people who are watching it. Please share your opinion on Reddit or something, not here.

Still a problem for me on 19w13b. Constant lag spikes making game unplayable.

Oh almighty Dinnerbone, deliver us from our chunk loading issues I beg of you.

Confirmed in 19w14a.

This is still an issue, Minecraft 1.14 snapshots are basically unplayable. Lag spikes, mobs stuttering when they move, I have chunk errors all over the place, when I fly through a world one chunk loads while others disappear and the village raids are so laggy that I can't kill mobs properly.

Just so people don't get confused on why comments get deleted: it has been said several times now on this tracker; this is no discussion forum, and any comments that don't add any useful information that's specific to the bug in question get deleted consequently. For discussion feel free to create a post on https://www.reddit.com/r/Mojira/

And just one last thing; developers are aware of this issue, and you can be 100% certain that ranting doesn't help here and it makes the bug not fixed faster. It can even cause the exact opposite when people lose motivation because of renting and pointless discussions.

Confirming this issue for 19w14a.. again. Makes testing anything extremely difficult as the game is near unplayable. 

@Michael Wobst we know that it does not help (obviously). The thing is we are realy scared when 1.14 is released there might be major bugs in there. I am on a few Snapshot servers and hardly anybody is playing. And when they are, they are more just waiting for the world to come up or trying not to get shot or blown up. It should be highly alarming that there seems to be nothing going on with this. No mention anywhere from the developers. Would be nice to here that this one (and the lighting bug) are really on Mojangs Top Priority list and they are doing whatever they can to get it fixed asap! We need time to test the snapshots to get bugs out but like this? So, I know this post will probably also be deleted, but hopefully that one of the major Mojang programmers could give us a bit of info on this?

Thanks!!!

Agreeing with Digit on this one. Can a dev give us an update on the state of this bug? Maybe some insight on the backend,  so people could be more understanding? Some transparency here would go a long way with the community.

@unknown Some bugs need a lot of time to be fixed. From what is publicly known, the mods do, in fact, suggest to Devs about bugposts, and not only that, it seems also Devs themself can add some form of priority or other form of annotations we regular users cannot see to a bugpost.

So just because we cannot see something from the outside like "do the Devs even know?" does not mean they truly don't know. I know that's a bit frustrating, I also sometimes wish there'd be some form of "we know about it" flag in some bugposts.

But just as a sidenote: This bugpost is assigned to a developer, so obviously they do have noticed it.

Uncertainty always causes fear and can, in consequence, also anger.
Thus I also always say that transparency would be great, for those kinds of bugposts at least which are vital to gameplay(, even though this takes up a good chunk of time which the Dev(s) could rather use to fix bugs like these in the first place).

I can understand your and everyone's frustration, but getting too worked up and to be aggressive can at some point cause exactly the same in those you're targetting:
The bugtracker mods as well as the Devs. They could get frustrated with and disappointed in this community. They all do their jobs (the mods even unpaid), and most of them surely do this out of their love and passion for this game.

Mr. Persson/Notch sold his Mojang shares to Microsoft exactly because of such a community behaviour (no, it was not majorly for the money, that's not how he was rolling, at least back in ~2013/2014).

So if you, like I, would like to keep some of the very first Java Devs for Java Minecraft, and making sure they still have fun developing this game and to continue to love this community (again), I suggest to be constructive with your criticism, and please, calm down.

@Meri Diana just a little note, it is not 'a good chuck of time' for them to just come over here (they have to anyhow to see what it is now assigned to them) and just add a little note about how or what. I am a developer myself, for a big company, and I also have to do some updates now and then. If we don't do that, then management is explaning that as a lack of interest in 'the customer' who would like an update now and then... So, for me it is a vital part of development to keep them a little bit in the loop before they tell me to stop with what I am doing... So on that part I just cann't really agree with you. If I don't see comments from them, then they are not there! And you or any other Mod can say everything they want, but you are not Mojang. And yes, sometimes I tell the customer just that we really did not get any further with the problem, but at least then they know.

I do thank the Moderators for keeping this issue-list and the comments in it nice and tidy. But for this really heavy case? There might be some mussle to help out.

So, @Mojang, @MojangDevs, @Nathan Adams, give us a little straw to pull us up on. Let us know what is happening. This bug is in here from almost the first 1.14 snapshot. Lets see something, pretty pleasy?

And thanks for Minecraft, I just really like it!

From what I've seen, it's almost as if it gets much, much worse for every player that's on the server. When I'm alone, it loads just as well as single player, but as soon as another player joins, both of us loading chunks at the same time makes both of our chunk loading nearly halt. I have noticed, however, that if one player stays still and another loads new chunks, the chunk loading is somewhat better, though not as good as in single player. If both players move together and load the same chunks, performance still takes a gnarly hit.

In support of violine's statement, please be aware that PhiPro has made a full analysis of this bug (explained it in detail in a comment on this bug report), and this analysis was passed on directly to developers. Fixing it is not a simple one-liner, so they have bandaided over it for now, with full knowledge that this bandaid doesn't really fix the problem.

Our server has a world that was generated in a previous 1.14 snapshot and we have been using the latest snapshots as they came. Upgrading to 19w14a caused chunk loading to be unbelievably slow - it could take minutes to load in a radius of ~5 chunks. Moving in certain directions near the edge of the loaded world causes single chunks to appear only moments beforeI am about to enter the chunk. However in some directions it is a hard edge and I have to wait a while for the chunks to load.

Reverting the world to 19w13b made it better again when it comes to overworld, however a similar issue persists when moving to the nether (as I recall, it did not occur before switching to 19w14a and back). Even then, on 19w13b the slow loading of the nether is multiple times faster than the situation described above. After a server restart the issue seems to go away for a short time.

Our world is lke 1.3GB but I can upload it to Google Drive if needed.

The server is running on Debian with a 3rd gen i3, 4GB DDR3 and a Kingston SSD.

Confirmed for 19w14b. I had to stop walking and wait for a minute before the next chunk got generated in a world that I quickly created within that snapshot.

EDIT: Also, these are my Game Settings, in case they're needed.

https://imgur.com/a/spKzyCT

@@unknown What's the server's render distance? It shouldn't matter anymore because it was supposed to be fixed in 19w14a, but there might be problems if the server's view distance is greater than your client's.

I think that they will fixed this bug in a pre-realease (very soon).

Confirmed for 19w14b. Server can't have a render distance beyond 6.

Just as a test, what happens when you disable auto-saving? ('/save-off' - available only on dedicated server, don't forget to revert with '/save-on')

Hey! That worked. Traveling between nether and overworld with 4~ players (view distance 12) caused a ton of chunk loading lag. Turned off auto saving and we load everything fine, even when loading into nether. I hope this helps!

Still in 1.14 Pre-Release 1

Confirming for 1.14 Pre-Release 1.

Issue: 3 or more players have extreme difficulty loading chunks with a server render distance of 7 or more. Once it is set to 6, we have no issues. Nether loading seems to still be an issue too. As stated before, turning off auto save helped with loading during nether travel but is obviously not a reasonable solution.

I have also been able to confirm this for 1.14-pre1! They better get this fixed by release; if players thought 1.13 had bad chunk generation, it will look like nothing compared to this (if they are able to explore or even load the world at all)! Edit: this is in single player, but it is worse on multiplayer

In case a mod perspective is wanted, I can also confirm this issue for 1.14-pre1. Loading chunks on a server is barely playable.

For those that can confirm, are you on singleplayer or multiplayer? If multiplayer, how many players are on when this occurs? Or does it happen with just one player on as well?

Hi Neko, When my server view distance is 12, the world chunks stop loading with about 3 people online. This is with and without players running away from eachother. Going through the nether makes things worse, sometimes not even loading when rejoining the server.

Singleplayer. The first time going from Overworld to the Nether worked but took quite a bit longer than usual. Then infinite Waiting for chunk... occurred when trying to go back to the Overworld. Trying to check out my old save. Update path: 1.10.2 > 1.12.2 > 1.13.2 > 1.14 P-R1.

After some fiddling/restarting managed a crash report.

From my testing on a singleplayer world, loading chunks with a render distance of 32 worked faster than a render distance of 4. Very strange behavior.

Single Player: After loading a game, it takes now 5 to 10 minutes before the chunks begun to load. This may be related to the fact that in my world in my neighboring village by the iron golem bug created more than 100 golems. After pressing the ESC key (pause mode), the chunks are loaded immediately.

This behavior also applies to chunks that are not loaded / slowly on travelling around the world (also far away from the iron golem village). In pause mode this chuncks mostly load immediately.

And as @AJMFactsheets wrote: Setting the render distance down affects nothing...

This ticket has described several issues over time. At the beginning, it was the issue that the clients chunks don't load if they ignore some server chunks (if local render distance is less than server view distance), but it is fixed.
Now we have another issue, but which can be perceived differently depending on your environment. I could test these snapshots on two different hardwares. The first one was a 2x1.9GHz with 2 GB allocated. On this configuration, the game was indeed sometimes "barely playable". The second configuration is a 8x3.5GHz with 16GB allocated. On this one, the game is running as expected most of the time, tested with up to 4 players logged in the same time and view distance of 8. The only situation related to this bug report is with Nether Portal: the game will hang out when someone is using a Nether Portal. But I found over time that if I force load the chunks where the portals are standing, it will entirely solve this issue except upon loading the first time after restarting.
Running a debug profiling during those times (when the bug occurs), and it says that

tick.connection.entityBaseTick.portal.placing

is taking too long (every time you cross any portal in unloaded chunks). I'm not sure if it's relevant, but I noticed the contribution of any

chunks.pollingChunks

is totally negligible during this process, looks like if the chunks were waiting any free tick time in order to poll. If it is the case, then the problem is completely something else; and seeing the "chunks not loading" is just a consequence of this.
I also noticed in correlation of what was said above that the contribution of

root.save

is far from negligible, and causes a warning every time the world is saved. And indeed, disabling auto saving seems to solve this issue. But manually saving causes a (controlled) lag spike in return.

I have done some testing on a 19w14b SMP I have been playing on, so I am not sure if it works in the 1.14 Pre-release 1 too. Might be a temporary fix, but I found that in-game Maps may potentially be able to "force load" chunks on the multiplayer server when chunks refuses to load (which usually happens when there are >3 people on the server), though it seems to cause a lag spike on the server a couple of times as well.

For some additional info, our server runs on 12 GB Ram, with a server render distance of 6, and is currently on 19w14b (We cannot update to the pre-release yet due to the chunk regeneration issues). 

Still in 1.14 Pre-Release 2

I could not confirm that the bug as written in the description is "Worlds will not load and/or if they seldom do, they load chunks very slowly." still exists in 1.14 Pre-Release 2.

I'm not sure that "Chunk loading/generation is slower than 1.13.2, as it appears to be loading chunks lazily, but have not done any quantative analysis, so my comments would be subjective.

But what I can state about 1.14 Pre-Release after testing is that when I'm flying around in creative on 1.14 Pre-Release 2, chunks might not get loaded around the player consistently like on 1.13.2, and it appears to fall behind in displaying them.  And certainly, after a while with render distance set at a high value like 32, the tick durations get higher and don't come back down immediately.  These problems "still exist in 1.14 Pre-Release 2" and are usability showstoppers.

Still happens in 1.14 Pre-Release 2, however it is much less extreme. I have tested the difference between 1.13.2 and 1.14 Pre-Release 2 chunk generation, and the 1.14 Pre-Release 2 chunk generation is roughly twice as slow (instead of at least 15 times slower). The chunks also generate/render less circular around the player in 1.14 Pre-Release 2, which may cause the remaining results of this bug.

We can't reproduce any of the issues described in this bug report anymore, and it's really hard to hit a moving target (chunks not appearing on the screen can be caused by any number of things going wrong in a looong chain). If you still have this issue, please provide exact reproduction steps if you can; if running singleplayer, please provide a screenshot with the debug screen open and the profiling graphs showing (Alt + F3); if running multiplayer, show exact server arguments + number of active players + at least a rough idea of what those players were doing; a debug dump from the server when the issue occurs will help too (can be obtained by running /debug start followed by /debug stop shortly after). If you can only reproduce it in multiplayer, try to trigger it with as few users as you possibly can, so we can try the same here. Thanks! 🙂

Georgeii, I didn't seem to have any issues reproducing this issue, but then, maybe I don't have the latest and greatest hardware. 

I can show you a video that was made that I used for the screen shots I posted on my other bug report.  It shows with the debug screen open and profiling graphs what happens.  It's a fairly large file, so I'll leave it posted on my server for a while until you can view or download.

https://www.spawnchunk.com/downloads/2019-04-12%2010-28-49.mp4

If you want to directly email/PM me for the details, please feel free to do so since release date is approaching and would like to get to the bottom of this.

This one is same hardware running real world test of highest rendering setting on 1.13.2.  Notice that although its lazily loading the chunks, it doesn't seem to have the tps issues.

https://www.spawnchunk.com/downloads/2019-04-12%2011-10-05.mp4

I was just testing similar issue (MC-138550) and I'm still able to reproduce this in different situations with different settings, more noticeable with render distance of 16 and above. I can definitely say, though, that this issue was way worse in some of the previous snapshots.

@unknown's video demonstrates exactly what I'm experiencing, maybe the ticket's description isn't as clear.

In my opinion, the problem might be that most people with mid and lower-end hardware could experience some consequences of this issue, like freezes or even crashes. I personally don't, and yes, this ticket doesn't state anything related to actual crashes. But even the game running on high-end hardware (like in my case), there are still big performance problems, one of which is this.

Chunk loading in 1.13.2 was certainly faster, it had bigger hit on the server performance (TPS) and a bit on the client (FPS), although flying quickly in creative mode or with an elytra wasn't a problem at all. Currently these actions lead to loading chunks unable catch up, the server struggling to keep running smoothly, and it's even worse when generating new, undiscovered chunks.

According to my observations, it seems like the chunk generation / loading was most likely moved to the end of each tick (or the idle time) to avoid delaying more important tasks. This might or might not be the cause of this issue in particular, but at least there should be some balance between performance and responsiveness. 1.13.2 and older versions were decent in terms of these two things, however the previous snapshots and these pre-releases, according to most people and me, definitely need more tweaking and optimization.

I appreciate the developers' hard work and effort to polish the upcoming release and fix as many bugs as possible, and would be glad to provide assistance or any additional information if necessary.

Custom JVM arguments may provide a better experience, but I don't know if it will end the problem immediately. Could someone test how these arguments work on their machine? I have a pretty good computer already, but it may benefit a low-end machine.

-Xmx2G -d64 -XX:+UnlockExperimentalVMOptions -XX:ParallelGCThreads=8 -XX:+UseSuperWord -XX:+OptimizeFill -XX:LoopUnrollMin=4 -XX:LoopMaxUnroll=16 -XX:+UseLoopPredicate -XX:+RangeCheckElimination -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses -XX:+CMSScavengeBeforeRemark -XX:+UseBiasedLocking -XX:+UseCodeCacheFlushing -XX:+EliminateLocks -XX:G1NewSizePercent=10 -XX:+CMSClassUnloadingEnabled -XX:+TieredCompilation -XX:MaxMetaspaceSize=200m -XX:+UseNUMA -XX:G1ReservePercent=10 -XX:+AlwaysPreTouch

I was testing with the integrated server in single-player with the default settings.  Of course the user should not have to 'tweak' JVM settings to get reasonable performance.

Additional notes about my test, there was a significant delay between typing /gamemode creative at the beginning of the game and that command thread actually being executed.  Perhaps something is blocking on load and save and may be related to why the game doesn't render the chunks periodically.  High tps issues, maybe those are also related to how the threading works now, since they seemed to be more pronounced when I changed video settings, and then loaded more chunks.  Feels like the threading can't keep up with the workload occasionally.

I can confirm that when casually playing, chunk loading now (pre-release 2 and 3) seems like before this issue was reported. 🙂

Sometimes it takes a while for one or the other chunk to appear, but it's a minor thing that may be related to connectivity or whatnot. Glad this has been allegedly fixed!

Has anyone tried multiple players on pre3 yet? That's where I ran into problems. My server ran fine until someone else joined, then it tanked. I can't test it right now, but I might be able to test it later.

Just tried pre3 with 4 players and that was fine. Went into spectator and flew around.
As mentioned, sometimes it takes a bit (talking seconds) for chunks to appear, especially when many entities are clogging the area (farms), but that's really how it has been before this issue and may be a client-side issue of some sort. Anyway, the problem of chunks never appearing was not reproducible for me anymore today and yesterday.

First time loading my existing world since the 19w14b snapshot, loaded it into the pre-release 3, not only do chunks load much faster, faster then in 1.13 to me anyways, but all the problem chunks that never loaded outside my spawn area also now load normally. I can finally finish my server map before 1.14 comes out. Thank you Mojang.

Just wanted to pop by  before this gets buried. Thank you for ironing out this bug, dev team. I know it was a hard one to figure out, but we really appreciate it!!

(Can't confirm for pre-5)

Can confirm for 1.14 release

@unknown, please create a new ticket if the issue persists in the release.

There is a new issue with chunks not appearing on the screen. And it can be reproduced just by casually playing a world. It seems to be a rendering issue as chunks seem to be blinking as you move the camera. This issue was not in pre-release versions. Which ticket is currently tracking this issue?

There are many new tickets for 1.14 release related to this issue, it's constant and consistent.  Fair to say Mojang should be ashamed this made it through and so clearly broadly effecting.

Go see MC-149239

It is not a performance issue this time. My world is running at solid 20 tps, but I still have this issue. This has to go with the client part.

Ticket [MC-149178] should be tracked for this issue.

New ticket about this is MC-149178

The issue persists. I noticed it in my older save files and decided to start a completely new one today (where my screens are from), only for it to be much worse. There is no stuttering or lag, just entire chunks staying invisible or see-through to lower areas. Mobs down below are rendered, however.