Your Mixer is causing TPS issues and crashing the server.
Boolyman opened this issue · 3 comments
Before reporting:
The issue has been reported multiple times, but the ones I have seen, you have closed without even responding (#3419). This has been reported by multiple players of my latest pack. This has been confirmed on multiple servers using TPS observing mods, and logs. Crash report below.
Description of the issue:
Your Mixer is causing major TPS issues and crashing the server.
Crashlog:
Versions & Modlist
Minecraft: 1.16.5
Forge: 36.2.29
Immersive Engineering: 1.16.5-5.0.7-143
Please provide a full crashlog, and any actual profiling data you have collected.
That little snippet does not help.
Within a default-like instance, literally none of the mixer "lag" is from IE.
Let's talk about some basic setup
I have two Spark reports here: one while it is running, and one while it is not, and both were for eight mixers running
running and not running
We'll be considering the one with the mixer running for most of this discussion, because it's got a greater tick value for the mixer
Please also note that everything here is taking into account all IE block entities, not even just the mixer
You'll notice here that IE is taking 3.58% of the server tick time. 1.93% of that is a a MC function for interacting with level data
Well what about that level code? Could that be fixed?
Level data code! What's it doing?
Let's talk generics about what this code is doing. A lot of it seems to be getting the redstone state and passing it through various functions. Of those, directly getting the redstone state from the world is ~1%, making the rest of the code (mostly MC, a little IE callbacks). So we're down to ~0.9% of the code that can be influenced by IE, because the redstone checks are sorta needed here. I think somewhere around 0.3%-0.5% is even influence by IE because at this point I gave up counting 0.01%s lost until my eyes bled. I'd like to point out that's like 0.01mspt maximum that IE could even possibly fix here.
Some additional notes on my environment for this test
Please note this is with
- all mobs killed, culled, and no entities existing but me
- a significant number of other sources of lag removed
Of direct IE code references where the losses are due to IE code running OUTSIDE of those mentioned above, that's about 0.26% of the total server tick. So 1.39% left over; of course, I'm sure there's a few small calls here and there it miight be more efficient to do in a different way, but we'll ignore those for now.
IE code doing IE things
So that 0.26% of total server tick is IE code doing IE things, purely, without the above level code stuff. The entire tick took ~1.89 mspt on average That means IE's causing, on average by themselves, about 0.004914 mspt of lag here.
Eight mixers. All running at once.
Sure, this is a "bad" way to do this, and probably underselling what IE might be able to fix, maybe; but most of the rest comes down to needed interactions with MC code you can't "just optimize" without mixins or breaking something other mods might rely on, and they're not really IE's fault.
Let's talk about the tick time before I had mobs disabled though
Before I had those disabled, though, I had 17% of the server tick taken up by mob AI, and 2.34% by TEs
spark report found here
For this profile, I had one mixer, four crushers, tanks back and forth filling on the pipe network, a bunch of other stuff. Both times I was using a potion recipe (awkward).
So we're talking not too many mobs in a simulation distance of twelve chunks (fairly standard for MC these days) are causing more lag than every IE TE I had combined plus all the Decor ones supplying items.
By almost 7.6 times
Sure, I only had like, oh, this many BEs in range (minus mixer tower, one mixer only; and plus 12 Decor BEs for crusher input)
Is this a small number of BEs? Sure! but almost every server has at least one mob farm: something known to cause far more lag from entity pathing than the commensurate number of IE tiles here. I've had bases with on the order of about a hundred times the number of IE tiles shown here exist, that's a whole, oh, about one eighth of the way to going below 20tps. These bases are well beyond an area of concern for most anyone, being of sizes as large as or larger than multiple times this size
IE literally does not scale this big by default. The pack above was designed to do so; and the base above is still smaller than needed for said "a hundred times the number of IE tiles". IE has no reason to go into insane BE hijinks to deal with whatever supposed lag you have.
Versions & Modlist
Forge: 40.0.49
[✔️] balm-3.0.2+0
[✔️] cloth-config-6.2.57-forge
[✔️] engineersdecor-1.18.2-1.1.22-b2
[✔️] entityculling-forge-mc1.18-1.5.0
[✔️] FastLeafDecay-28
[✔️] feature_nbt_deadlock_be_gone_forge-2.0.0+1.18.2
[✔️] ferritecore-4.2.0-forge
[✔️] ImmersiveEngineering-1.18.2-8.0.0-147
[✔️] inventoryessentials-forge-1.18-4.0.1
[✔️] jei-1.18.2-9.7.0.180
[✔️] JER-Integration-3.2.1
[✔️] JustEnoughProfessions-1.18.2-1.2.2
[✔️] JustEnoughResources-1.18.2-0.14.1.160
[✔️] Placebo-1.18.2-6.2.1