Repurposed Structures (Forge)

Repurposed Structures (Forge)

21M Downloads

[1.18.2 Forge] Slows down server startup

embeddedt opened this issue · 5 comments

commented

👋 I'm working on optimizing startup performance for some modern Minecraft versions. Some profiling in 1.18.2 led me to discover that your mod adds about 10 seconds to the integrated server startup time on my system. The culprit appears to be the server startup event handler that registers your structures in the pool.

image

I didn't see DFU needing to be run on 1.16, so I was wondering if you reused the same structure files for 1.18.2 without upgrading them first? That would force DFU to run on them every time the server starts up, which is probably not intended.

I am aware that you don't support 1.18.2 anymore, but wondered if this might be relevant for the 1.19.x versions as well.

commented

1.18.2 is not supported correct. You can try this to see if it runs in 1.18.2 to help make a datapack of upgraded structure nbt files to override rs’s https://github.com/SuperCoder7979/structure-fixer

I can try running this in 1.19+ to make sure the structure files are all updated as I am heck not doing it by hand when there’s probably 1000+ structure nbt files by now

commented

Looking closer at the pic you showed. That code path is not actually RS’s internal nbt files. That’s DFU running on the pool_additions nbt files which are datapack added pieces. You can load and re-save the nbt files from the RS compat datapacks by structure blocks to update those nbt files. If you have vampirism or waystones, they have special nbt pieces they add to rs villages so you’ll have to override those by datapack as well. Those are the pieces that goes through the pool_additions codepath

commented

Thanks, really appreciate you taking the time to look into this. I implemented a caching mechanism to save the upgraded version of any old structures and reuse those cached versions if possible. This seems to have completely fixed the issue.

commented

Your laptop is probably substantially faster than what I'm profiling on (Core i3, 4th gen, so dual-core with 4 threads). I am also using LazyDFU to avoid DFU rule optimization slowing down launches significantly, so that probably makes DFU even slower. All in all, it's good to hear that this isn't an issue on more powerful/parallel hardware, but caching definitely shows a noticeable improvement on my system.

I am also looking forward to 1.19.4 once all my mods are available for it. :)

commented

Interestingly enough, even after I adjusted the nbt presence check in the pool_additions code and upgraded all the nbt files in my mod in 1.19.2, I tested against a single player world startup and even had on a bunch of RS compat datapacks to hit the pool_additions code hard. All that on my laptop and the only difference in world load time was under a second. I don't think DFU is actually hitting that hard for my mod. The 8 seconds you were seeing in the profiler doesn't make much sense unless another mod was doing cursed stuff that affected how well DFU parses?

But all this is kinda moot anyway as 1.19.4 made DFU insanely crazy fast. I'll try and keep my nbt updated but past 1.19.4, the dimishing returns becomes kinda nothing. But for now, i guess I can barely shave off one second?