Suggestion on performance: stuck when placing a pipe in a large network

[yuyuyzl]

I think it's recalculating the whole network data and store them in the pressure input right....? This is very good idea for increasing efficiency while running but if i try to add or modify a large network it will be a disaster on my server because it will cause the server running for minutes calculating the data.

And I know it may be pretty hard, but i still want to suggest you to learn from AE when facing a large network, just make a queue for the whole network, and do only a few blocks of calculation in one tick, decide which ones to calculate next, and save the state to next tick, finally you will finish the pre-calculation without making a huge lag.

BTW this network is for a ReactorCraft fusion reactor, including more than 4 kinds of liquids in one network, 180+ outputs & about 20 inputs. Total pipe length is 500 pipes and including circles.

I wish this will be better, i love the infinite transfer speed XD

[bdew]

When you place or break a block there is a scan that tells all inputs that the network has changed, and they update their own view of the network on the next tick when something actually goes through them.

Yes, it does store all state in input blocks. It's a design tradeoff, allowing pipes to be dumb blocks without tile entities or any kind of state and the network to work across unloaded-chunks.

That being said, a network with your size is shouldn't be taking anywhere near that long to update.

I've just built a network with 576 pipes, 192 outputs, and 32 inputs, and a full rescan takes ~0.033 seconds on my PC. So there must be something else going on here.

Can you spawn (using NEI or creative mode) a Pressure System Debugger and right click a pipe on the network? It will generate a lot of chat spam, but the last line will contain how many blocks it scanned and how long it took.

If it indeed takes minutes - i'd be interested in looking at profiling data from the server (using VisualVM or something similar) to see what it's actually doing.

Some additional ideas:

• Check that your server isn't low on memory, the process can be a bit memory-intensive and cause a lot of GC activity if memory is already low, slowing things down a lot.
• Try not placing pipes exactly on the edge of chunkloaded space, during a scan they need to check all nearby block, which would cause the non-loaded chunks nearby to get loaded.
• Try placing check valves or routers at strategic locations, splitting the network into smaller parts.

[yuyuyzl]

well sorry for ignoring this for 4 days :P . but i tried to use the [stick] to my pipe system in the server and it shows 484 blocks scanned, and it took 15673440 μs, in fact it is reasonable but when i add a pipe to the network, the time used is soooooooooooo long that all players were kicked out because [Timed out]. I think it took five minutes maybe. i agree GC may cause the problem, the memory of my server is 1480M / 4622M, not too much...? still wondering why.

[bdew]

Hmm... that's 15 senconds for a scan, then if all the inputs are updating that's 20 times that which is about 5 minutes... yeah.

No idea why it's that slow, similar-sized network on my test system takes 0.03 seconds wich is like 500 times faster. Doesn't make any sense to me tbh.

Added: Now i would really like to see profiling data from those 5 minutes.

[XFactHD]

I don't know if this matters when using pressure pipes but from what I know from other pipe mods, it is generally bad to have to many junctions instead of one line (building unnecessary circles). When looking at the screenshot, there is a ton of those, maybe try this with some of those connections blocked by FMP covers.

[yuyuyzl]

Oh, it's [number of pipes]*[number of inputs]=[total time] XD, so i merged the 12 same inputs for liquid nitrogen to a ExU drum and then to the main network, and it really works. Now the refresh time is.... acceptable to me, and i choose this morning(in China) , nobody is in server, to finish my reactor design. Still no idea why it take so long, but solved half of my problem. Thanks.

[bdew]

from what I know from other pipe mods, it is generally bad to have to many junctions

Not really true in this mod, loops and junctions are fine as long as it involves only pipes. Bad loops (that involve valves or I/O blocks) are detected and explode immediately.

[number of pipes]*[number of inputs]=[total time]

Not exactly, but yes - each input block maintains their own view of the network, and will run their own refresh on the first tick that they receive fluid to push after the network has changed. So reducing their number should improve performance on changes.

At any rate, since you figured out a solution and i don't see anything i can really do with currently available information i'll close this issue.