Updates to fluid pump networks cause abnormal amounts of lag

[InspectorBoat]

Describe the Bug

Updates to a fluid network with at least 1 rotating mechanical pump cause extremely high amounts of lag. This includes wrenching or adding new pipes or pumps, and block updates in front of mechanical pumps. This lag appears to scale nonlinearly with the size of the network. This can be an issue with pump based cobblestone generators, as cobblestone is rapidly formed and broken in front of each pump.

Reproduction Steps

1. Create a network of fluid pipes and mechanical pumps
2. Give rotational power to at least one pump
3. Press Alt+F3
4. Wrench any pipe or pump, or place a block in front of the exposed end of a mechanical pump
5. Observe large MSPT spike ❌

Expected Result

Lag spikes should not occur.

Screenshots and Videos

https://github.com/Creators-of-Create/Create/assets/116048347/744a4f6e-2bef-4986-826b-6a0464f5583b

Crash Report or Log

No response

Operating System

Windows 11

Mod Version

0.5.1f

Minecraft Version

1.20.1

Forge Version

47.2.0

Other Mods

None

Additional Context

No response

[Flexz9]

While testing an upgrade to latest Create on 1.20 I've noticed the same. Lag from vaults is replaced by 11%+ of MSPT going to PumpBlockEntity.

https://spark.lucko.me/v3wsm38G0W

This was a single base loaded.

[Flexz9]

PumpBlockEntity.patch

This patch includes some changes to use multithreading. This significantly decreased MSPT

I've made a similar test as shown in the video. [14:16:45] [Render thread/INFO] [minecraft/ChatComponent]: [System] [CHAT] Overall: Mean tick time: 262,036 ms. Mean TPS: 3,816

After the changes I wasn't able to make it go beyond 10MSPT. This will lower the lag created from cobble farms and lava farms. I assume these would create the biggest issues.

This patch should be tested a bit more..

Edit: I put the patched jar on the server. From 0.88ms (previous shared spark) to 0.28ms https://spark.lucko.me/fsE7zCelE9

[Flexz9]

The pump seems to not work in very specific use cases.

PumpBlockEntity.patch

What I tried to do now is start from the endFaces and follow the already found path to the pump. I also check if the following face is already in the valid faces as it would be possible that another endFace is closer and already marked the required path. In these cases we can stop for that path.

This should reduce the load a little bit and we can process each endFace in parallel.

I'm still able to generate a ton of updates to make it start lagging. But it is not as bad as it used to be.

[JacekRatajewski]

how can i patch .jar file with .patch file?

[Flexz9]

You shouldn't if you have to ask. It's also for any developer who can resolve this better then me to see what I tried.

But it introduces an issue that some pipes don't work in all directions. But it's also not always the case. Not sure what is happening there

[skylord-a52]

Pump lag seems to scale with the area each pump is connected to. Making your pipe network more sparsely connected can radically reduce lag, as (I imagine) each pump has to search less area.

Here's an example from a lava farm I built. It consists of a 16x16 square of cauldrons, each with a pipe underneath, forming a fully-connected grid. At the front and back of the farm are a row of pumps. In this first image, the pumps at the center of the 16x16 square can take up to 400us per tick. This is about five times more than a lot of mobs!

But if we cut out all the pipes in the center, splitting the network into two halves, pump tick time drops by two orders of magnitude.

If instead of a grid, you lay out your pipes in rows like this (staggered so they dont connect to each other), I'm sure the performance benefits will be even greater. (I haven't had time to test this yet, but judging by the results from just splitting the grid in half, it seems like a safe bet.)