Please use the search functionality before reporting an issue. Also take a look at the closed issues!

Issue description:

Pipez in combination with QuantumEntangloporter = massive TPSs drop
[Note got send here by pipez dev as he mentioned its a mekanism issue]
henkelmax/pipez#29

Steps to reproduce:

Build this setup: https://ibb.co/1T8M2j3 (use in the log file below)
The red line indicates a cut between the QuantumEntangloporter channels
*optional8 apply the used config https://pastebin.com/HXSrGtiN (Makes pipez the same as mekanism)

Thermal Machines MUST be used as they seem to be linked to the huge TPS drop. When using Mekanism I have yet been able to produce this issue as easy as shown here.

The issue seems to be as followed. When using pipez in combination with a mekanism QuantumEntangloporter and Thermal expansion it massively drops the TPS. Please note that just building a quick 1 Thermal machine does not do the trick Please see below the setup that was used together the the Spark mod output info

Version (make sure you are on the latest version before reporting):

36.1.2
ATM6 1.5.10b

If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)

Note that ONLY the machine on the right top is smelting zinc/copper dust to make Create brass.
All other machines remain off !
Profiler ran for 30 seconds before switching to the next setup

Idle mode: 20 TPS
https://spark.lucko.me/ktH6PXrSus
Setup 1: Server running at 20 TPS
https://spark.lucko.me/u0GRfvLAyv
Setup 2: Server running at 20 TPS
https://spark.lucko.me/SB7k6MMTCy
Setup 3: Server running at 20 TPS
https://spark.lucko.me/ib7U6YirpA
Setup 4: Server running at 10 TPS
https://spark.lucko.me/aAUWOHCVfT
Setup 5: Server running at 4 TPS
https://spark.lucko.me/cJwkkO0Y1b
Setup 6: Server running at 4 TPS
https://spark.lucko.me/7UGCGOeXn8
Setup 7: Server running at 4 TPS
https://spark.lucko.me/09G8Qe3S3e
Setup 8: Server running at 4 TPS
https://spark.lucko.me/dLIna1xOGR
Afterwards back in idle mode: https://spark.lucko.me/oRJhYue88x

From a brief glance I am pretty sure this is a pipez issue, and more specifically due to this extremely inefficient energy distribution implementation. Just to list a few issues with it:

1. Each iteration of the loop it looks up the tile entity from the world again (not that big a problem but is not ideal)
2. From what I can tell while simulating it doesn't take into account the fact that if it had more energy than it needed for distribution purposes it will keep going and think it can keep accepting it as the destinations don't actually change how much is stored when simulating so they still will likely be able to accept energy if they were able to accept it before. This is especially problematic if massive amounts of energy are being attempting to be sent as how they have their loop setup it will loop until it gets rid of all the energy so if say each destination can only accept one FE and MAX_INT is supplied it will loop MAX_INT times in simulation. I believe something along these lines is what is actually causing the TPS issues here. This also ignores the fact that some mods really don't like when you try to force insert (with simulate disabled) multiple times per tick (EnderIO in 1.12 was a big mod that stood by this and would even make the incorrectly implemented mod's blocks explode to get them to stop causing TPS lag) which their distribution implementation does (though thankfully unlike their simulation version at least is able to exit early and not potentially loop an extremely high number of times.

Our networks and auto eject systems are written in a way to try and evenly distribute between all possible destinations (so for energy cubes and entangloporters and stuff each side of them). The rough overview of how it does this is:

1. Simulate sending our entire amount to each target so we get the total amount it would be willing to accept so we don't have to calculate it again.
2. If it is less than our amount per target when evenly split would be then we send it
3. Recalculate the amount per target if it changed due to some needing less than we could offer them
4. Actually send the amount we partitioned to the given destination

My guess is steps one and four are the ones that are causing pipez to have a stroke with that poorly implemented distribution system of theirs as:
We simulate insertion with a large number given the setup you are using. This then causes pipeZ to query the world a ton and also all the destinations it has potentially thousands or hundred of thousands of times to simulate inserting into them (when any simulation on a given destination isn't even valid after the first simulation). pipeZ would then return to us that it can accept the large number we asked if it could. This causes us to then believe them that they can accept it and try to send said large number to it, which then causes pipeZ to have to query all the destinations again (though not as many iterations as it will exit early when the destinations are full).

It should now be fixed in the latest version of the pipez mod. Our "poorly implemented distribution system" is now working like it should before the energy pushing changes and should be more efficient than mekanism again.