Title ^

Info

Recently our server has been taking hits with TPS lag. Did a Spark Profile and it looks like Nature's Aura is taking up 40% of the entire server. Down to almost 2 tps.

Versions:

Forge: 39.0.9
Minecraft: 1.18.1
Nature's Aura: 35.3
Patchouli: 1.18.1-63

Spark Profile Link: (Click Eye (all) on the right.)
https://spark.lucko.me/4NH9jdAqfu

(de.ellpeck.naturesaura.Helper.getLoadedChunk() is currently taking up 41.58%

Seems to have helped, thanks! New profiler results show that Nature's Aura is no longer causing the TPS jitter (although it seems that another mod I run is running into the same issue): https://spark.lucko.me/XKl7UbT7MW

Hm, so is there anything on my side I could do?

Wait!

That's pretty much it though, sadly. Probably gonna do an update tonight or tomorrow. We'll see.

Server now proceeded to crash. (ServerHangWatchdog detected that a single server tick took 180.00 seconds (should be max 0.05))
https://gist.github.com/Gbergz/8f74ad9ebf1b801d70e2b5c98005574c

absolutely screaming at the fact that the thing that is tanking TPS is a method that I added this comment to a long while back:

// DO NOT EDIT PLEASE FOR THE LOVE OF GOD
// This is very finicky and easily causes the game to hang for some reason

Would you mind trying again with this version? It might be a lot better, but it might also be unchanged. Yay?

Didn't work with that one, same lag.
New profile: https://spark.lucko.me/ccwGXXJVAl

Apparently my first attempt was done still half asleep, looks like ServerChunkCache.getChunkNow (ChunkSource.getChunkNow) does almost exactly the thing below + caching (it does that in a less efficient way, I don't know why, the code below may be at worst late by one tick in seeing a newly added chunk, I also don't think the cache would actually be any faster if it was done as below). There seems to be no way to access ChunkHolder without going into internals (I got used to working with it).

getChunkFuture will always wait for the target status if the chunk's target status is the same or above, even if it's not loaded yet. hasChunk also tells you about the target ticket level, but not whether it's actually there right now. There is isPositionTicking which does use what is actually currently loaded.

getFullChunk runs exactly the code below, but it's private too.

if you want to get loaded chunk, I think that would be the way to do it (completely untested, but that's based on my understanding of how the system works, we use code similar to this for ingame chunk status visualization):

    public static ChunkAccess getLoadedChunk(LevelAccessor level, int x, int z) {
        if (level.getChunkSource() instanceof ServerChunkCache cache) {
            ChunkHolder holder = cache.getVisibleChunkIfPresent(x, z);
            var future = holder.getFullChunkFuture(); // alternatively, call getTickingChunk() to get a LevelChunk that is already guaranteed to be in ticking state
            return future.isDone() ? future.getNow(ChunkHolder.UNLOADED_CHUNK).left().orElse(null) : null;
        }
        return level.getChunk(x, z, ChunkStatus.FULL, false);
    }

There is also another method to get an entity ticking chunk, as ticking doesn't necessarily imply entity ticking. Ticking chunks are guaranteed to have radius of 1 chunk around them in full status. entity ticking are guaranteed radius of 2.

It looks like you've already identified the code causing problems, but if you wanted more data, I am also running into this issue on a server that I run. Issue appears as high jitter in TPS (regular TPS is fine; some ticks occasionally take a long time). Here's a spark profile: https://spark.lucko.me/CH6JN8tryN

I'm running the same versions of everything as the original poster.

What abooouuuut this version? Seems to be pretty good from my brief testing. Fingers crossed.