Chunk Generation Performance Regressed by 20-30%

Having the same issues on my server. Even with a pregenerated world loading chunks creates ridiculous lag

Any news ?

Doesnt look like it. Guys this is a serious issue that needs to be fixed. Can we assign this issue soon

@unknown we don't assign issues to mojangsters, they do that them selves

Absolutely by "we" I meant the team of devs. It would be great to see some activity on this major issue. It effectively renders the game unplayable if players explore - which im sure you understand and agree is a fundamental part of the minecraft experience that currently servers are struggling to deliver. It's somewhat disapointing to see a game breaking issue, that has a fix provided in the original report to still have NO progress made on it 😞

The issue has been open for less than a week, and they have many other high-priority issues to fix that didn't make it into 1.9. The change that caused this issue was made deliberately, and presumably for a good reason. The fix provided may help Mojang in understanding and fixing the issue, but probably can't just be dropped into the original code due to obfuscation, and they may not want to fix it in that way for the same reason they made the change in the first place.

The Minecraft development team doesn't make heavy use of the project management features of JIRA, such as assigning issues, because they don't have a lot of people to coordinate between, and can do so informally or using other internal tools. Issues are frequently fixed without being assigned, or are assigned and then fixed shortly thereafter, rather than being assigned in advance. The tracker is here primarily for their benefit, and not as a means of publicly displaying their development activity.

It is inconceivable that this problem because so let's say it's a problem, is not fixed quickly, and indeed I began worried that no solution is found at present.

Is desirable that this infamous bug chunk of generation is repaired quickly.

It's unfortunate that they do not keep us updated on whats going on. I disagree this is not a high priority issue and I will leave it there. Thanks for the advice that this system is not worth using to watch tickets.

@unknown

"The change that caused this issue was made deliberately, and presumably for a good reason. The fix provided may help Mojang in understanding and fixing the issue, but probably can't just be dropped into the original code due to obfuscation, and they may not want to fix it in that way for the same reason they made the change in the first place."

Actually, us developers will look at code, see 2 things that appear to do the same thing, but miss the slight difference in the 2, or worse, don't clearly see what happens deeper in the flow.

So we then say "let's simplify things! Delete the extra". We test, and everything works... So it seems like a good idea. Deleting code usually is a good thing.

But in this case, the problem isn't seen until larger servers, and until Mojang starts testing updates against 100 player servers...It's going to rely on the 3rd party community to clean up the mistakes, as we're the ones that have in depth profiler data on how the code behaves under heavy load.

The devs don't copy and paste our patches directly of course, but they'll know how to apply it based on logic (hince "paper patch 78" was mine [except for the part that got modified and caused bugs] as well as 2 other performance changes I contributed that landed in 1.9)

Ok, but when can we hoped that our servers again become playable?

You can use Paper server which contains the latest fixes to 1.9 performance problems (some spigot doesn't have atm)

https://aquifermc.org/threads/paper-for-1-9-official-release.51/

Actually, us developers will look at code, see 2 things that appear to do the same thing, but miss the slight difference in the 2, or worse, don't clearly see what happens deeper in the flow.
So we then say "let's simplify things! Delete the extra". We test, and everything works... So it seems like a good idea. Deleting code usually is a good thing.

If you have two functions that do mostly the same thing, then your code is poorly structured, and it's likely that changes or fixes that should be applied to both will only be applied to one, causing bugs. Mojang may not have considered the performance impact of consolidating the two functions, and may not have consolidated them correctly, but consolidating them was still a good action to take. Maybe an additional argument should have been added, or maybe the unload queue shouldn't be managed within that function at all.

@unknown, I didn't say that this wasn't a high-priority issue, only that it wasn't the only one. Everyone always thinks their favorite issue is the most important, and that the developers should drop everything else to work on it, but it's clearly impossible for them all to be right. In this case, I would argue that the official Minecraft server software is generally not sufficient for servers with a large number of players, and that most of them run alternative server software, such as the Paper server @unknown has mentioned.

MODS, My server is not a large server we have a community of around 30 players and an average online count of 6. At no point have I suggested I run a "large" server. I Never have more than 12 online at a single time and so if the official minecraft server software is not sufficient enough for that then we have far greater issues than chunk generation. This underlines even more so how important this issue is for the devs to be working on and not adding elytra sounds! The idea that I run some huge server is just wrong and being used as a reason as to why the game is not working correctly. The fact is your game is horrendously broken and the priorities of the devs seem to be WAY off the mark. Having tested the issue on the same hardware I used problem-free for 1.8. The issue is present with only 2 players online (this has been mentioned a couple of times by other members in other posts) which means the issue is NOT limited to large servers.

I do completely believe that we should be getting some actual feedback on this matter and not mods speculating as to what is going on. It seriously doesn't take much for someone who actually knows what's going on to say "Hi guys, I'm here, we're on it" however right now we are getting 1.9.1 Pre-releases with no fixes listed that match the report and no feedback on this ticket.

I understand this particular one is a heavy undertaking when compared to adding elytra sounds as it needs a total rework. It feels like its just being ignored in favour of an easier ride. You say mojang resolve things internally, while this may work well for them I suggest that those who report issues and aid in the game's continued improvement be given the courtesy of up to date feedback. This is my feedback on the matter for future issues as above I am no longer watching this one - getting totally fed up it. We try to help make this game better and its like everyone sticks their fingers in their ears because its to much work.

The chunk queue / calculations on server seems an awful waste of resources. Instead why not hand off the calculation to the client to come back to the server with the generated index, in that tap into the client's actual CPU cycles if it reaches a certain perf / benchmark (easily detectable).

To then counter "hacking" attempts (ie never trust the client) you then ask someone another client that's connected the server (randomly) to verify the calculations etc. If there are no other's on the server, it's only then does the server perform the calculations in a thread.

The point is, start offloading CPU cycles to the mesh network that which is player(s) to do as much as the heavy lifting as one can without impact to perf of their experience. Using a transaction pub/sub system ?

@unknown that doesn't have anything to do with this issue and would not be a good way to improve the server. That would extremely over complicate the design and make it even harder to make real optimizations.

@unknown I wasn't saying simplfying code was wrong. I totally agree that when you see things that appear to do the same thing, to condense it. I was saying that this regression was very unlikely to be intentional, and a mere side effect of the change, as you previously implied they intentionally changed the behavior of the code to always touch the unload queue, and I was saying I disagree and I believe the unload queue behavior change was merely an unintended side effect.

@unknown- Stick to managing what's in/out with SpigotMC and also to what you "know" vs "think". As that reads "I think" vs "i know", as until you can substantiate the opinion provided with provable / tested code that illustrates the ROI failures in this equation, then really, it's about offering alternative options to just "bug fixes" whilst highlighting ways a refactor or deferred by design can occur. Fact is there's a cloud of CPU's available to hand off workable tasks to clients, even if its discrete calculations that are obfuscated.

If anything why SpigotMC hasn't done an out of band patch to this issue (thus reducing constant bottle necks currently been seen) probably summarises the peak abilities being on offer here.