Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Performance issues with appeng.helpers.PatternHelper.isValidItemForSlot ? #3411
Today, I start profiling my server to detect some issues with the performance.
Our central ME Network does lot of stuff in the same time, e.g. process some periodic crafting with crafting cards, import and export a lot items, transfer over a million RF via P2P Tunnels.
There is no "I do this that not the performance goes down". Maybe you 'll finde some caching issues or I ll need some help to identifiy the issue.
This is pretty much the worst case, we can no longer mitigate in any way and have to reach out to forge for the crafting result. Which is literally the worst possible option and forge seems to have no intentions to improve it.
In general we can only cache items without NBT to avoid using the actual recipe or worse
In this particular case it is even worse, as the actual recipe rejects the input as valid item and we have to reach out to
So there is not much we can actually do about it. Maybe besides logging the offending recipe to identify it.
I was considering some changes to patterns in rv6, but they should not have any effect in this case. Mostly to reduce the memory consumption a bit for identical patterns (unlikely as long as there is no way to normalise recipes provided by forge) and mitigate some issues with high frequency chunk unloads/loads (somewhat rare, but it could have some benefit). With some actual data about how often it actually takes that path and be successful, it might be worth to throw out the fallback path in rv6 or later. With regards to 1.13 it might be good idea as some mod dev will have the glorious idea to stuff everything into a single item id with thousands of NBT values to replace metadata and constantly forcing it into the
Btw. is there a different way to contact you, like IRC, or maybe discord, etc? E.g. in case I have some ideas and need a guinea pig server.
Did you try it to start a discussion at forge or are the issues at forge rejected?
I would like to help you. But I don't have any idea about the internals from forge, AE2 or Minecraft itself. I'm not a java developer.
If you have a own discord, I could join yours. I also have Slack oder gitter.im
Not in this particular case, but e.g. in regards to the poor performance of
I just leave a temporary discord invite here. It is more of a team/dev oriented server currently. Still not that convinced about using it for end user support. The usability is a bit lacking and it is too easy to miss stuff.
added a commit
Mar 5, 2018
@yueh We're having the same issue, if you need a second test case. Saw the same hotspots come up in visualvm/warmroast. I'm familiar with minecraft development and internals, and some forge internals.
EDIT: Was thinking about trying to hack in some kind of profiling mode into the mod. Also wanted to do the same for ThermalDynamics to help profile routing issues there. But alas, more problems than time :(
If you want, you can test #3412, either the CI build or if not possible compile the branch yourself (e.g. as drop-in replacement serverside).
By default it will log every recipe, which is a total failure and forge cannot even provide an alternative recipe. Or when the debug and crafting logs are enabled it will log every recipe taking this branch. But this could still be a valid option, just some mod having a non ideal approach to handling similar recipes.
In general, we did identify Mekanism as one cause. Due to them stuffing everything into a single item id and encode the actual tier or other data completely as NBT, these recipe will constantly fail. This can also easily affect TD as it requires an expensive NBT comparison for any kind of filtering instead of just the fast int comparison for item ids, metadata or damage value.
There are a few things we could still improve. But these can have major sideeffects. So short term I really want to avoid breaking a large amount of mods/patterns/recipes, just due to 1 or 2 mods being somewhat broken. Long term we should certainly remove this code path and just ignore mods, which add a single recipe per oredict entry instead of a combined one. Or forge actually improves recipe handling contrary to all expectations.
This could actually improve it. As would make it easier to distinguish different items. So no longer would
But I totally expect that a few mods will decide it sucks and it would a great idea to break it and just have a