World.setKeepSpawnInMemory ignored?

[ninja-]

When loading a world with setKeepSpawnInMemory(false)
(either set a WorldCreator level, or at WorldInitEvent level, I do both)
it should load instantly.

Instead, it takes over a second to load on 1.12.
I am migrating from 1.8 and see this buggy behaviour.

Plugin list:

A list of your plugins
No 3rd party plugins.

Actions to reproduce (if known):

1. Create a new World with WorldCreator
2. Set WorldCretator's setKeepSpawnInMemory(false)
3. Count time it takes for createWorld() to complete
   It should be near instant, but takes more than a second on 1.12.

Paper build number:

[13:39:06 INFO]: This server is running Paper version git-Paper-1143 (MC: 1.12) (Implementing API version 1.12-R0.1-SNAPSHOT)

[ninja-]

I see that Paper has added keep-spawn-loaded to paper.yml world config.
Changing it to false does not fix this.

Paper 1.8
[13:48:55 INFO]: Loading world #2 (load) took 24ms.

Paper 1.12
[13:48:30 INFO]: Loading world #2 (load) took 1157ms.

://

[ninja-]

This patch looks buggy.

https://github.com/PaperMC/Paper/blob/5e40806ee260d12b4b0572b366f4d9a5b53bef76/Spigot-Server-Patches/0013-Allow-for-toggling-of-spawn-chunks.patch

The method to load keep-spawn-chunks-loaded is created, but it's not called anywhere, nor I can see this debug printed.
Additionality it would override plugin's choice of this, even if fixed to work properly.

[electronicboy]

the method is called with the reflection in that class, beyond that, the field is read on creating the world and set in the class, it likely boils down to the fact that in 3 years the amount of data stored in a world has increased along with additional processes done during loading a world increasing the time required to load the world

[ninja-]

No, it's not called, I would see a debug print of Keep spawn chunk loaded...
(ok, I see it's magically calling every method in the class, but still it doesnt work)

[ninja-]

Also I can see the chunks loaded in the heap...when I haven't even joined the server since start.

[electronicboy]

That setting doesn't stop chunks from being loaded, it only allows the chunks to unload. The server also doesn't log those settings unless verbose is turned on

[ninja-]

Right, I turned on the verbose and can see the stuff loading.
But changing this always(1.0-1.8) stopped the spawn chunks from loading.
This may be a regression.
Should I dig into it?
The current behaviour and the cpu time it eats is unacceptable for me.

[ninja-]

Ok, I changed the class that creates the world from .zip template to copy the level.dat file too (it only copied data and region)
Appearently I had some reason to exclude it back then like maps that had a gamemode forced in level.dat etc. on some weird settings.

Now it's down from 1000+ to 378ms.
Now, where is the rest of the time going?

[electronicboy]

level.dat contains stuff like the UUID,sharing it between worlds will cause issues with loading them.

Also, the rest of that time goes to actually loading the world, worlds have many settings attached to them that need to be loaded at startup... You can check the process by looking at the nms world classes, I'm currently unable to use my main computer right now.

[ninja-]

ok I got some initial profiling data...might be an easy fix. I'll let you know once I analyze it.

WorldServer. - 1000ms
WorldServer.a(WorldSettings) - 3290ms
WorldServer.b() - 5143ms
-> AdvancementDataWorld.a() -> ChatDeserializer.a()

-> LootTableRegistry 1500ms
-> WorldServer.canSpawn 2750ms

(some terrible like ~ 10x profling overhead, but still)

[MiniDigger]

As electronicboy mentioned it loads all the new stuff the world now saves: loot tables, advancements, functions etc

[ninja-]

Yes, and I am quite dedicated to fixing(removing as I don't need this mostly) that to get 1.8 start performance and finally stop using 1.8 Paper :(

[ninja-]

Disabling advancements in config makes startup better already, I'll look into the rest of it.

[zachbr]

Closing, there is nothing wrong with the option specified.

You have already created a separate issue for a problem area you have identified. As (if) you identify others, you should create separate issues for those specific areas. We will handle any necessary discussion in those tickets as they are created.