Set Bonus

Set Bonus

10M Downloads

[1.12.2] Possible Performace hit with Had Enough Items?

SonicX8000 opened this issue ยท 8 comments

commented

Opening this issue for the time being as I try to narrow things down and I figure I mark down what I've found so far.

In my modded survival world with like... 300+ Mods... I noticed a major performance hit when updating Set Bonus. The version I am using is...

SetBonus-1.12.2.031

...as this fixes a crash that happens with Had Enough Items. I can list the mods, but since it's... a rather large amount of mods... it'll be a long list. With Had Enough Items the performance tanks quite badly to the point that the game is a slideshow. If I happen to open up the JEI Menu I noticed that the items are slowly being registered in one by one which is rather strange to see though it lessens if I put in certain text words to shorten what items get looked up and that actually eases on the performance hit, though I do see some items get loaded in one by one as time goes by.

HEI has a config option called # Enable ultra low memory usage mode, can slow down searching by a lot however. which will actually fix this performance hit, but at the cost of recipes & such taking a few seconds to load in or... taking like 10+ Seconds to search up items in the search bar which... kinda isn't ideal in the long run.

Now... if I downgrade to...

SetBonus-1.12.2.020

...which was the last version I used at the time before noticing that Set Bonus was being updated again... there was barely a performance hit, if any at all, even though having THAT many mods installed may cause performance issues but of the times I ran with this many mods installed, there really wasn't any problem until I updated Set Bonus.


Another test I tried. I swapped out Had Enough Items with Just Enough Items (jei_1.12.2-4.16.1.1013) and went back to SetBonus-1.12.2.029 since that version crashed with Had Enough Items. (It's fixed in it's newer version, though I noticed a dip in performance when equipping items that have a set effect applied which will be it's own issue with MUCH less mods added, though I will mention that the more mods or... rather... the more items that are added in, the higher the performance decrease you'll run into with it cutting your frames and it lasting a few seconds or so.)

After doing that... no performance hit, if any, even if I equip any items that have a set effect there doesn't seem to be a performance dip, though if I should use SetBonus-1.12.2.031 there will be a performance dip when I equip items that have a Set Bonus applied to them.

I can upload the mods in a zip if you really want me too... but I am unsure if you'll want to deal with like... 300+ Mods or so. Maybe there's a conflict happening but it only started when I updated Set Bonus while using Had Enough Items.

If any logs / debug are needed. I can provide them, will just have to set up another instance with the many mods and swap between different set bonus versions & such.

commented

Right, so first I'll clarify why there is any performance hit at all with 1.12.2.031 (and some before that if on JEI).

The performance hit is from reloading all tooltips of all items in the modpack. This is how I made it so that you could search for eg...
(1/2
...to find items in the modpack which would count toward a set that you have 1 of 2 items for equipped already.

This is something JEI and HEI simply don't do. They normally only load tooltips once before any real gameplay happens, which means that if a tooltip changes after that, you won't be able to search the changed tooltip correctly. They DO reload tooltips if you do F3+T, but that's going to get you a nice long freeze ofc. I think HEI might also reload them if you change certain config settings, but yeah, so that's where the hit is coming from in the first place.

This means that eg. HEI will not have a performance hit from this at all if you use Set Bonus of a lower version than 31, because it simply didn't do this for HEI yet, which means you wouldn't have dynamic tooltip searching either.

In other words, it's not really a versioning issue, but rather that the performance on very large packs is apparently still not ideal. Right now it's set to spend at least 10ms/tick reloading tooltips if they need reloading, which could cause a bad client tick rate if the client's CPU is already near max capacity (on the main thread), so that's likely what's happening.

None of this happens when using HEI's ultra low memory usage mode, because it's not compatible, so that's why you don't see the hit there.

Thanks for testing btw, it helps when someone knows how to post a good issue report.

SO, I need to find more possible solutions on the efficiency. Things I'm considering right now:

  1. A config option to disable the dynamic tooltip search feature that I added, removing the issue but also the feature

  2. Changing (possibly via config) to PARTIAL dynamic tooltip search, ie. only reloading when you discover a new bonus and no longer properly tracking changes in met-requirements status

  3. Removing the minimum time spent on reloading tooltips per tick (when tooltips are realoding). Right now it always spends at least 10ms, but I could remove that minimum limit and the performance hit might no longer be noticeable. The side-effect is that the item list would take longer to finish reloading

  4. Multi-threaded tooltip reloading; right now it's only using the main thread...this is probably what I'm leaning toward the most atm, as it may have the most potential for approaching the intended behavior without causing issues

commented

Notably, I haven't had a large enough pack set up to get the same level of performance hit you seem to have. I might have to set up a large pack first to get a good environment to test in. I'll download a big one and see if I can get the issue to happen on my end.

Edit: I also think I'll combine the first 2 possible solutions into a "Dynamic Tooltip Search" config setting with 3 modes (full, bonus discovery only, and off) regardless of what else I try in addition

commented

If need be I can send you the mods that I'm using.

commented

I think any pack large enough will likely get the same result, but if not then I might ask for it later.

I'm going to implement that config setting right off and release a new version when it's done, then I might get a large pack set up and do additional testing for other solutions.

commented

1.12.2.032 has the config setting I mentioned, and it will default to "on new bonus discovery" mode, so I expect it will help a lot as-is if you drop it in. It should be available soon.

I've started the download for a modpack with "over 500 mods" so hopefully that will be enough for any further testing on my end. I'll take another look at this in general after I sleep.

commented

That 500+ mod pack was unlrealistic to run (took too long to load), but I've replicated the performance hit in another (somewhat randomly chosen) pack (Steampunk's Paradise).

Notably, this issue only happens when your client's CPU is already just barely keeping up / not keeping up with the modpack (on the main client thread).

For now, I suggest using Set Bonus 1.12.2.032 and keeping the dynamic tooltip searching mode on the default (1) (on bonus discovery only).

I'll see if I can manage a threaded version of tooltip reloading and/or other optimizations.

commented

Version 1.12.2.033 will be available soon. It now has threaded tooltip reloading, but I still suggest keeping the tooltip reload mode in the Set Bonus client config on mode 1 for packs with lots of items and/or lots of mods that mess with item tooltips.

The only extra feature mode 2 adds right now is the ability to search your CURRENT set requirement status (eg. 1/2 if you have one out of two set items equipped), at the cost of needing to reload whenever that changes. It won't update the search results to the correct ones until the background thread actually finishes reloading tooltips, which can take A LONG TIME in extra large modpacks.

I still have at least one more decent idea for improving efficiency on mode 2, so I'm leaving this open for now (note to self: look in TODO file).

commented

Alright, my last main idea for more efficiency is not looking very realistic. This is likely the final state of JEI / HEI tooltip reloading for now.

I expect mode 1 to be the go-to choice anyway, and it doesn't really have an issue. Mode 2 likely won't get much use, if I had to guess.

Let me know if you still come across an issue with mode 1.