Logistics Pipes

Logistics Pipes

13M Downloads

[1.7.10] Question: Is there a way to improve performance, even if sacrificing speed of operations?

cheesealmighty opened this issue ยท 4 comments

commented

Hello there, while I'm aware any "months old" world would suffer from TPS spikes, it has become quite unplayable recently. While I followed good practices (i.e. no pipe lattices, disable pipes with gates, use unrouted pipes in between long sections, etc.) it seems like it doesn't help any more.

This is the opis log, I can provide a visualJM snapshot you'd like as well: https://puu.sh/BspVJ/53cf23a4ed.png

I've considered the possibility of this being similar to #909 and #1042, as I'm a proud owner of a "the wall" but removing the drawer controller did not prevent TPS spikes from happening.

In hopes of improving stuff, I've swapped some config options:

B:enableParticleFX=false
I:reDetectionFrequency=6000   (10 times the default)

I've tried disabling multithreading, increasing multithreading, decreasing and increasing the priority of multithreading. Nada.

Is there a config setting to improve this overall? Some sort of throttle for the pipes so their calculations are done slower? (I'm not sure how this'd work, as this'd create a backlog of tasks, probably.)

Would removing speed upgrades from pipes work in my favor? Or using the old render (probably not since the issue is TPS related)?

commented

If you could provide a full visualVM snapshot that would be great, because then we can use that to find the code parts that are probably responsible for your tps problems. That could also indicate if the problem is similar to any of the mentions issues.

Particles are more heavy on the client and should not cause tps loss, same goes for the old vs new pipe rendering.

Multithreading is only for our network tables and as long as you have problems even if you don't change your network, then changing those settings will not help either.

Sadly there is no config option and not even a constant inside the code that could be changed to reduce LP's overall "work per tick". Although that is something that should get added to our todo list.

Maybe we can help you out, when you have uploaded a visualVM snapshot.

commented

This test was done on my local computer. Here is the snapshot: https://www.dropbox.com/s/d5zt0irlk2tf87w/logisticsPipesLocal.nps?dl=0

Also here is my world, along with my modpack:
https://www.dropbox.com/s/k20v8viaunmpfrn/Backup-rotatebaby-2018-9-10--0-27.zip?dl=0
https://minecraft.curseforge.com/projects/bad-times-and-big-machines


I should add that unfortunately I did the switch to AE2 for the bulk of my system, however uninteresting it may be. I kept part of my setup (ie my jet fuel facility) and server is doing fine. So I guess I'll mostly use LP for local setups (which may I add, does an amazing job of.)


Edit: Gah. Never mind. That system just turned on, and oh boy did the TPS drop.

commented

From what you have uploaded, I can not find any place where it would be easy to reduce the server load. The problem is, that the main consumption of performance is buildcraft and logisticspipes moving items. So sadly there is no quick way to help you out.

commented

No worries. Thanks for taking the time.

overall "work per tick"

Would probably have been useful.

Also, have noticed extractor module ends up creating an endless stream of items especially when dealing with ReikaMods (ie. 1 operation/tick stuff). Maybe there could be a pipe that moves a stack (or more) at a time, but less often.