Straw Golem Rebaled

Game Info
Game Version : 1.16.5
Mod Version : 1.9
Mod Loader : Forge 36.2.20

Describe the bug
This is in the Create: Above and Beyond modpack v1.3.

As title states, this mod is causing extreme lag for some reason, but I haven't even used anything from the mod.
I started to notice this weird, repetitive lag spike about once every second. I opened the ingame profiler (Alt+F3) and saw this:

As you can see, this is a brand new world I made to troubleshoot this lag issue that I first encountered on my main world. I was very confused as to why the lag spikes persisted in a new world, so I made another one - no lag spikes in the second newly created Super Flat world. Odd.

This modpack includes Spark, so I used it to profile the world with lag spikes: https://spark.lucko.me/hs1JtFSJQf

Drilling down, you can see that 94.58% of the tick was spent on com.commodorethrawn.strawgolem.events.CropGrowthHandler.tick(), specifically on java.util.AbstractQueue.remove()

I looked at the 1.16.5 code for CropGrowthHandler and found the offending line but I'm not sure what's happening. It looks like at the end of every tick phase, it calls PriorityQueue.remove() to remove the head of the queue until it's empty? According to JavaDocs, this is O(logN) so it's very efficient - I wonder what the hold up is? Is the queue extremely long for some reason and that's why it's taking so long?

strawgolem/src/main/java/com/commodorethrawn/strawgolem/events/CropGrowthHandler.java

Line 58 in ee5049d

queue.remove().execute();

strawgolem/src/main/java/com/commodorethrawn/strawgolem/events/CropGrowthHandler.java

Lines 181 to 192 in ee5049d

    
           public void execute() { 
        
               if (world.isBlockLoaded(pos)) { 
        
                   if (isFullyGrown(world, pos)) { 
        
                       EntityStrawGolem golem = getCropGolem(world, pos); 
        
                       if (golem != null) { 
        
                           golem.setHarvesting(pos); 
        
                           return; 
        
                       } 
        
                       scheduleCrop(world, pos, --count); 
        
                   } 
        
               } else scheduleCrop(world, pos, count); 
        
           }

You enqueue these events in the subclass there. I wonder if line 191 is a typo and it's supposed to be --count for the final parameter like it is in line 189? Either way, I reckon you might want to not even schedule crops if there's not a nearby golem?

To Reproduce
Steps to reproduce the behavior:

I'm not sure the rhyme or reason. I imagine it might be my proximity to crops that causes it? I tried roaming pretty far out in my main world into the middle of an ocean (where there shouldn't be crops, unless kelp counts) and I was still suffering from the lag spikes. On the first new Super Flat world I created, I didn't even have to move for the lag to begin. On the second Super Flat, I didn't move and there was no lag.

Screenshots
See above

Additional context

I hopped on the FTB/Modded Minecraft Discord to see if anyone could clue me in. While waiting for the mandatory 10 minute timer before I could post, I was searching for "strawgolem" based on the results of the profiler and found someone saying:

4/05/2022
Are you running Create Above and Beyond?
For that pack, it is recommended to remove the Exotic Birds mod and the Strawgolem mod
They both for some reason cause very large amounts of lag
https://discordapp.com/channels/166630061217153024/345415812481286144/960935666894655608

Confirmed TPS lag is gone after disabling this mod and reloading the world that had lag issues.

Neat! I'm sure that'll resolve these random lag spikes for people on C:A&B if the Create Team decides to update the 1.16.5 version, but at the very least there'll be a tangible solution to point at if people have issues like I did.

What got me was that I hadn't even used your mod yet, and I've been playing on this world for about 2 weeks before the lag began.

Anyways, thanks for the quick response!

I’m not entirely sure, but the whole crop handling is entirely rewritten for the 1.18/1.19 multi loader branches.

If memory serves, priority queues lose the log(n) performance when they become unbalanced, which easily happens after many insertions/deletions, so that could likely be it. The newer system uses octtrees which don’t have this flaw

i should be able to get a release for 1.18/1.19 out by the end of the month, and it’ll then take me about a week to backport I think.

Thanks for all the effort you’ve put into looking at this!

Yeah, there are issues with the 1.16 version. Once the 1.18 branch is stable it will be backported as a final update for 1.16

I'm curious as to what causes it, do you know?

I’m not entirely sure, but the whole crop handling is entirely rewritten for the 1.18/1.19 multi loader branches.

If memory serves, priority queues lose the log(n) performance when they become unbalanced, which easily happens after many insertions/deletions, so that could likely be it. The newer system uses octtrees which don’t have this flaw

i should be able to get a release for 1.18/1.19 out by the end of the month, and it’ll then take me about a week to backport I think.

Did you never end up doing the backport? The last 1.16 release is from 2020.

nah, life got in the way a bit, i rewrote the whole mod again and theres an alpha release for 1.19 fabric on modrinth - i still have to port that to forge, fix some things with it, port to 1.20 and then back to 1.18, i probably won't backport all the way to 1.16 realistically

im closing this because, while ive decided (as of roughly 1 minute ago) to start supporting the mod again, i really don't think i'll have time to backport all the way to 1.16 at this point

	public void execute() {
	if (world.isBlockLoaded(pos)) {
	if (isFullyGrown(world, pos)) {
	EntityStrawGolem golem = getCropGolem(world, pos);
	if (golem != null) {
	golem.setHarvesting(pos);
	return;
	}
	scheduleCrop(world, pos, --count);
	}
	} else scheduleCrop(world, pos, count);
	}

Share to