Shinoow / AbyssalCraft

Source repo for the AbyssalCraft mod
GNU Lesser General Public License v3.0
82 stars 50 forks source link

[Suggestion/Enhancement] Improve/rework item transport system for performance #518

Open jchung01 opened 3 months ago

jchung01 commented 3 months ago

First of all, nice to see you back to modding after what looks like quite a while!

Is your feature request related to a problem? Please describe. The current item transport system in this mod using the Spirit Tablet is not particularly great for performance. It iterates through all loaded tile entities every server tick, so in a large base in a modpack, this event handler can take up a meaningful amount of tick time even if the player does not utilize this system. Here is an example of some profiling I did. Keep in mind that this is a profile of a world that does not use Abyssalcraft's item transport system at all, it just has a lot of tile entities in the world.

Describe the solution you'd like As you may be able to tell, I implemented a more performant version of the system in Universal Tweaks (UT), but I figured I would let you know of my implementation in case this is something that you may want to tackle. Feel free to adapt my implementation if you're interested, or rework your system in a better way. My current implementation uses World capabilities to mark and store specific tile entities configured by the Spirit Tablet/Configurator so the event handler is not so performance intensive. You can take a look at it in the UT repo here; some of it is implemented through mixins, but I believe you should be able to get a general understanding of how I have implemented it.

Describe alternatives you've considered You may want to come up with a better alternative to the system than the one I've implemented, as mine still does depend on logic happening every server tick.

Additional context The more optimized implementation I have in UT was meant for use in Abyssalcraft 1.x, so I figured if you want to improve upon the item transport system in 2.x, you can check out my implementation. After all, it would be best to have such an improvement directly in the mod and not through a separate mod using mixins to modify your code. Of course, this is not an urgent or necessary suggestion, I just wanted to let you know of this performance sink I found back when I was using the mod in a large modpack.

Shinoow commented 3 months ago

Thanks for looking into it! I'll take a look at your solution and put something together. Will probably implement changes on both branches, since hogging resources in the back when the thing in question is not even being utilized falls under whatever category I use for making a 1.0 backport of changes.