I'm seeing abnormally high event subscriber usage for tinkers on my server while in a large area cleared down to bedrock with a builder and fortune clearing card. When I move far away from the area tinkers drops back off the chart. I've reached the limit of my knowledge and don't know the next step in tracking down the culprit.

https://i.imgur.com/45nvhlY.png

https://sparkprofiler.github.io/#ysSbtWWBbv

Versions:

• Minecraft: 1.12.2
• Forge: 14.23.5.2847
• Mantle: 1.3.3.55
• Tinkers Construct: 2.13.0.171

This is in Enigmatica 2 expert 1.72b no sponge or anything

That'd be the spawn logic for blue slimes on slime islands and magmacubes on magma island.
The logic is fairly simple, it just checks the spawn position against the existing slime islands in that dimension, which should be relatively cheap.
I can see only 2 potential places that would cause it to take longer:

• Is your world very large?
• Does the modpack have a ton of different mobs that can spawn?

I would say a little of both. Do you know why its only a problem when I'm in the area I cleared and not the rest of the map? I didnt see a config to disable slime spawns, is there anything else I can do? Thanks!

There is no way to disable slime spawns. Disabling slime islands would mean no all slime spawns, since the islands aren't there, but not for already generated islands.
I found another potential spot, which is removing the other spawns.. I saw that the implementation Forge uses actually could cause some performance issues if there's a lot of mobs to spawn.
Maybe that's why it only happens in the cleared area.

Can you try with this version? You need to unzip it first, since github doesn't allow jars.
TConstruct-1.12.2-2.13.0.DEV.1d2981b7b.jar.zip

It does confirm that the combination I was worried about is not at fault. It also shows us that there's
no easy solution to the problem. Only thing that'd be left is changing how slime islands are stored to reduce the lookup time, which requires more work. If that even is the cause.

At this point its just a matter of curiosity for me but I'm still intrigued. I'm sure the way I imagine most of these things working in my head couldn't be further from reality so I'm just spitballing. When I cleared the area it also cleared the slime islands (I probably should have explicitly mentioned this) so wouldn't I expect to see less of the associated decision making going on as opposed to more? I've had issues in the past with the rftools builder in the sense that it can break things because it removes blocks without causing block updates, any chance something like that is going on here? Thanks again.

This build doesn't seem to make any difference. I've moved past it so its not a big deal, but I'll keep it handy should you have any other ideas. Thanks for your time.

At this point its just a matter of curiosity for me but I'm still intrigued.

Same, which is why I'm looking into it more ;)
I made sure the performance is feasible back when I implemented it.

You're somewhat correct, but there's a bit more going on. I assumed you cleared the islands, but slime islands actually work similar to nether fortresses. You know how wither skeletons only spawn there? Same principle. We track every slime island and when spawning check if it's trying to spawn on a slime island (simple greater than/smaller than position check). Slime islands are never removed (since we don't know if all the blocks are gone or not, and we really don't want to check all blocks inside the island for air every time)

Here's what's going on:

• Loop through all slime islands of the dimension, and check if the position is inside it
• If it is inside, remove all possible spawns and add blue slime/magmacube instead

From a performance perspective this boils down to:

(O(n) * O(1)) + O(m)
where
n = number of slime islands in dimension
m = number of possible mobs that can spawn.

Initially I thought O(m) would be O(1), which means it's constant and we hence don't care about the mob diversity. But It turned out to be O(m) so I gave you a version without it, to see if you had a very large n and m which became noticable. Also O(m) only has an impact if the game is actually spawning a blue slime, otherwise it's zero.

From what I've gathered so far that is not the case, and it simply is n that is large enough to become noticable. Especially if the game tries to do it multiple times per tick (don't know if this currently is the case).

So the only thing that's left is not to check all slime islands, which requires a different approach on how they're saved.

So, I'm gonna close this since I really don't want to mess with how that's saved for now. Probably a topic for 1.15.