[1.15.2] Questions regarding the overhead of tickable tile entities

[DavidM]

Hello.

I am creating a pipe block that can transfer items from one chest to another.

This would require a tickable tile entity.

However, since most of the pipes are not directly connected to a chest, but rather act as a connection between two pipes that have direct connection to chests, the majority of the pipes are not responsible for extracting items from inventories every tick.

I am wondering whether it is a good idea to remove pipes that are not directly connected to a chest from the world's tickable tile entity list to avoid having unnecessary virtual invocations on ITickableTileEntity#tick, and re-add a pipe into the tickable list if a chest is placed near the pipe later on.

Would this actually make the game perform better?

Edited April 10, 2020 by DavidM

[poopoodice]

14 minutes ago, DavidM said:

Hello.

I am creating a pipe block that can transfer items from one chest to another.

This would require a tickable tile entity.

However, since most of the pipes are not directly connected to a chest, but rather act as a connection between two pipes that have direct connection to chests, the majority of the pipes are not responsible for extracting items from inventories every tick.

I am wondering whether it is a good idea to remove pipes that are not directly connected to a chest from the world's tickable tile entity list to avoid having unnecessary virtual invocations on ITickableTileEntity#tick, and re-add a pipe into the tickable list if a chest is placed near the pipe later on.

Would this actually make the game perform better?

I think so, and I'd recommend master-slave system

[DavidM]

25 minutes ago, poopoodice said:

I think so, and I'd recommend master-slave system

Please elaborate. I don't see how the master-slave pattern is applicable here.

[Animefan8888]

43 minutes ago, DavidM said:

Would this actually make the game perform better?

Yes it should. because it would be less function calls and less stack manipulation.

5 minutes ago, DavidM said:

Please elaborate. I don't see how the master-slave pattern is applicable here.

It's kinda applicable. All the Tickable TE's would be considered a master and all the non Tickable TE's would be considered slaves. Mind that you do not even need a TE for slaves if there is nothing to store there.

50 minutes ago, DavidM said:

This would require a tickable tile entity.

Sure it could require a tickable TileEntity. Or you could abstract another layer out. This is my preferred method for implementing pipes.

Having many Tickable TEs would require them all containing a connection network. Or running a pathfinding algorithm every time you want to send something from A to B.

 

However if you instead take away their autonomy just a little and instead store a "Network" of pipes in the world via a Capability and interact with it every tick with a World Tick event. You then save memory by only storing the connections once and you can cache the shortest/determined path between point A and B.

[DavidM]

Thanks for your replies.

 

14 minutes ago, Animefan8888 said:

It's kinda applicable. All the Tickable TE's would be considered a master and all the non Tickable TE's would be considered slaves. Mind that you do not even need a TE for slaves if there is nothing to store there.

In my case, I am checking if an applicable inventory is placed next to a pipe via Block#updatePostPlacement, and add the pipe to tickables if there is one. The same goes for removing inventories. The TEs are responsible for storing whether the connection on a direction is disabled the player.

 

18 minutes ago, Animefan8888 said:

However if you instead take away their autonomy just a little and instead store a "Network" of pipes in the world via a Capability and interact with it every tick with a World Tick event. You then save memory by only storing the connections once and you can cache the shortest/determined path between point A and B.

My current approach is to path find every time the network of pipes is updated (i.e. removal/addition of pipe or inventory, changing of the configuration of a pipe, etc), and assign each extracting pipe to a set of inserting pipes (with matching configuration/channels). Every tick the extracting pipe sends items to the stored inserting pipes. There is no actual connections of the pipes is memory.

[Animefan8888]

18 minutes ago, DavidM said:

My current approach is to path find every time the network of pipes is updated

So your current approach is to query the world for every block in the network every time the network is updated. This works but is sadly a slower way having to access the World for every block and connection direction.

20 minutes ago, DavidM said:

and assign each extracting pipe to a set of inserting pipes

This is still stored in memory. And you have the same set of inserting pipes for every extracting pipe on a network.

[DavidM]

10 minutes ago, Animefan8888 said:

This is still stored in memory. And you have the same set of inserting pipes for every extracting pipe on a network.

Not exactly. Since each extracting/inserting pipe can have different channels (extracting pipe will only target inserting pipes with the same channel) and configurations (i.e. closest first, round robin, etc), the set of inserting pipes and the order of them might vary for each extracting pipe.

 

13 minutes ago, Animefan8888 said:

So your current approach is to query the world for every block in the network every time the network is updated. This works but is sadly a slower way having to access the World for every block and connection direction.

I might have understood this wrongly, but I am not aware of other alternatives for this. If I understood correctly, my current approach and the approach you illustrated above both require the updating of a network if there are additions/deletions to the network.

[Animefan8888]

Just now, DavidM said:

my current approach and the approach you illustrated above both require the updating of a network if there are additions/deletions to the network.

Yes but my method already knows of all the pipe connections, where as yours does not. You have to do something like.
for Direction dir : Direction.values()

  TileEntity t = world.getTileEntity(pos.offset(dir));

  // Etc.

Where as mine already has a Set<BlockPos> where that is all of the connections. This set is updated when a block is placed or removed from the network. Then pathfinding runs on this set. Which also allows it to run on a separate thread as the World is not thread safe.

[DavidM]

7 minutes ago, Animefan8888 said:

Yes but my method already knows of all the pipe connections, where as yours does not. You have to do something like.
for Direction dir : Direction.values()

  TileEntity t = world.getTileEntity(pos.offset(dir));

  // Etc.

Where as mine already has a Set<BlockPos> where that is all of the connections. This set is updated when a block is placed or removed from the network. Then pathfinding runs on this set. Which also allows it to run on a separate thread as the World is not thread safe.

I see. I’ll switch to your method for performance.

However I am not sure how to obtain the network given the position of a pipe in it. How would that be accomplished (without iterating through all of the existing network)? I am thinking of given all pipes a reference to its network, but there might be a better way.

Edited April 10, 2020 by DavidM

[Animefan8888]

4 minutes ago, DavidM said:

I am thinking of given all pipes a reference to its network, but there might be a better way.

You could do that or if you use HashSet you get constant time checking if it is in the Set. So the finding the network that contains this position is O(n) where n is the number of networks.

[TheGreyGhost]

Hi

The best piece of advice I can give is:

code it the easy way, then stress test its performance.    I'm betting that even ticking hundreds or thousands of pipes is not going to drag down the game performance by a noticeable margin.

Although you could build a parallel data structure to record the pipe network, I wouldn't recommend doing that unless really necessary because it's harder to code and maintain, and keeping the data structure current (detecting all changes) could be quite difficult to get right due to chunks loading in and out.

Your idea of a fast exit tick if not next to a chest is a good one I think, because it would be fairly simple to implement.  There are several methods for blocks that are fired whenever the neighbour is updated, so a pipe can easily keep track of whether it's next to a chest.  You wouldn't even need a TileEntity, a block with three blockstates (start, middle, end) is probably enough if you use scheduled ticking.

When your "I'm next to a chest" tick occurs and discovers that the chest has an item in it, it can then hunt its way through the pipe network to find the chest at the other end; given this is very infrequent I can't imagine it would be a big burden.

 

-TGG