Utilization spike/hiccup after every loot event

[Gaviin1242]

In retail, using v4.0.14, after every looting event, there is a brief but noticeable CPU utilization spike (I assume) that results in a hiccup in FPS. This happens maybe half a second after the loot is processed.

I've tested with just enabling/disabling ATT, and it is definitely the cause.

[DFortun81]

Try disabling every addon other than ATT and then do the same test.

[Gaviin1242]

Yes, with no other addons but ATT on, there is no hiccup.

I've tried many many combinations of disabling certain subsets of addons -- particularly ones that have been recently updated, because this problem is new -- while keeping ATT on to narrow down which other one may be combining with ATT to cause the issue, but no luck so far. And just to reiterate, if I keep every single other addon active and only disable ATT, the issue goes away. So I'm rather confused on this one.

[ImUnicke]

@Gaviin1242 There is a little bit of quest refresh logic linked to a finished loot operation, but in Retail it's extremely efficient and I'm suspicious that you're noticing this particular event. In addition, this logic tends to be hit due to other criteria events that Blizzard sends to the client literally every time you jump ... so if you want to go somewhere in game that you typically get high FPS, and just jump repeatedly. Let me know if you notice any hiccups under this circumstance.

I'll continue to investigate a little if there might be anything else triggering logic on looting.

[ImUnicke]

Also, there is extra logic tied to looting after killing a Boss to refresh your saved instance information. You say 'after every looting event' so I'm assuming you experience this issue while just out in the world looting regular creatures?

[ImUnicke]

@Gaviin1242 If you really want some spam in chat to try and narrow down whether some ATT event is linked to this stutter. Kill a bunch of mobs to have some loot ready. /run ATTC.Debugging = 1 /run ATTC.DebugEvents() Then loot the mobs and see what goes into your chat. You can screenshot that here for reference as well. To remove the debugging use /run ATTC.Debugging = nil /run ATTC.DebugEvents()

[Gaviin1242]

There is a little bit of quest refresh logic linked to a finished loot operation, but in Retail it's extremely efficient and I'm suspicious that you're noticing this particular event. In addition, this logic tends to be hit due to other criteria events that Blizzard sends to the client literally every time you jump ... so if you want to go somewhere in game that you typically get high FPS, and just jump repeatedly. Let me know if you notice any hiccups under this circumstance.

Interesting, but no, I don't notice any hiccups when jumping or doing any other regular activities in game.

Also, there is extra logic tied to looting after killing a Boss to refresh your saved instance information. You say 'after every looting event' so I'm assuming you experience this issue while just out in the world looting regular creatures?

Yes, this is looting anything. Mobs, treasures, etc.

I'll try that debugging stuff a bit later. Really appreciate the help in trying to figure out what's going on here. I've had to disable ATT until it gets sorted, and I miss it. :)

[milotic]

@ImUnicke since DF was a little lag spike looting things what your character cant learn but in raids the spike can be worse and end in a lua error in the part of rolling dices: https://github.com/DFortun81/AllTheThings/issues/1710 or get kicked from the server with a lua error in legacy boss like ulduar boss: https://github.com/DFortun81/AllTheThings/issues/1770

[Ricodyn]

I've been encountering the same problem and it seems like a weird issue. After some testing in the open world, this issue didn't seem to be related to ATT for me, but it was caused by my bag addon Baganator. Updating that to the latest version removed this stutter issue in the world.

In Delves however this problem remained and after a bunch of testing I found the issue to be a combination of both ATT and Saved Instances. Running either addon by itself causes no problems, enabling both creates the stutter after every loot event. I've obviously updated both addons to their latest versions but that doesn't solve the issue. I've also quickly jumped into a dungeon to see if the issue exists there for me, but no. At the moment I think it only happens in Delves, though I haven't tested in a Raid.

So what exactly happens for me is that about 1 second after I open the looting window (actually looting is not required for this issue to occur) I get a small stutter. Something I also found that might be helpful is that for the first looting event of a session, I get a 2nd identical stutter about a second after the first one. Every other time I try to loot is just that first stutter, until I /reload and I get that single occurrence of a double stutter again.

[Gaviin1242]

Well I'll be. You're absolutely right about the interaction with SavedInstances! I can confirm that running ATT without SI enabled (and vice versa) fixes the loot stutter. And this occurs anywhere for me, not just in delves. Out in the world, etc.

I don't notice a 2nd stutter after the first loot of a session, just FYI. And I've never used Baganator, so that hasn't been a factor for me.

[Gaviin1242]

cough

Not sure what inconsistency you think you've identified. Yes, I acknowledged that with no other addons, ATT works fine. But obviously that's not a sustainable solution, since, well, I kind of like my other addons too. :) And I previously indicated that I tried a bunch of combinations of ATT with a narrower set of other addons disabled, but couldn't find the culprit. Ricodyn found it, and I was able to confirm.

We're still stuck with not knowing why ATT and SavedInstances don't play well together. Is it something ATT can fix independent of SavedInstances? Vice versa? Or do both need some kind of update?

And to reiterate, this is a newer issue, as I've been running both addons together for a very long time and only recently did this loot issue start happening.

[Exodius]

My apologies, I've misread the transcript.

[AlexSoft1911]

@Gaviin1242 do you have this issue right after login or some time after in game session (2 hours or more). I currently have 2 different desktop setups and they have a 'something' like that not exactly.

One can become an frickery after time in (usually around 4 hours session mark without any client restart/logout) - which starting to throw 'script run to long' for almost all addons (despite they still working without issue) and hiccups/spikes in-game client for no reason and this is a thing until client is restarted. This desktop is semi-old. Second desktop have to do some hiccups after (sometimes (!) 12-13 hours mark), there also running with savedinstance+ATT all the time here. This setup newer.

I currently have speculation that depending on hardware setup wow acting really odd at this moment and sadly there no universal way to solve it from my experience.

[Gaviin1242]

This happens immediately upon login (i.e., as soon as I can kill and loot a mob), and as far as I can tell, persists indefinitely.

[ImUnicke]

I removed a pre-registration of the LOOT_CLOSED event, which we only want to hook after the BOSS_KILL event is fired. That then tells us we can request an update of your raid info via RequestRaidInfo() This then triggers the event UPDATE_INSTANCE_INFO when ATT then uses to update your character's saved instance data (for checkmarks in instances, tooltips, etc.) And of course Saved Instances also hooks into this UPDATE_INSTANCE_INFO event to perform some updating of their own:

  self:RegisterBucketEvent("UPDATE_INSTANCE_INFO", 2, function()
    SI:Refresh(nil)
  end)

So with LOOT_CLOSED event hooked later on, such that ATT will only trigger this instance refresh after a BOSS_KILL event has been captured first, the small stutter should only happen when looting after a boss (or whatever Blizzard tells us is a 'boss')

I'll mark this as closed for now, but please re-open if after next release or latest Git testing the issue continues to persist in the same manner.