10-20 second lag spike when changing dimension
The easiest example is going through a portal, but multiworld setups also do it. It seems to be proportional to the amount of explored chunks (tested in multiplayer, have not tested in singleplayer). I'm using DH 1.6.9a on 1.19.2
I used perf to trace what was eating so much time and found the render thread pretty much idle while
LodDimensionFil was dominant, with ~half it's time in shaded.tukaani.xz.lz.Matches shaded.tukaani.xz.lz.HC4.getMatches. It seems DH blocks everything while it saves to disk? Perhaps we could do that asynchronously, or perhaps solving issue 250 would be good enough.
I do have other mods installed, so I'll get you a cleaner trace with just DH if you want.4 Replies
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
I know it can load LODs somewhat asynchronously because I see them slowly load when I join a server, and joining doesn't block for 10 seconds. I'm pretty sure this lag spike is from saving to disk, which I imagine would be relatively easy to make asynchronous at some memory expense.
This lag spike also happens after I change the renderer type to "Disabled". EDIT: I suppose this information doesn't add anything
The reason why we have to block the render thread when saving is because we need to keep the DH level the same while saving.
If we start saving, and a new dimension is loaded, we could end up either missing something in the save, or saving the wrong thing.
I've been throwing around an idea in my head that we would only save any un-saved data when changing dimensions or leaving the world, which should theoretically prevent this lock up in most cases. However I haven't done any research into doing that yet.