For context, I have 120 buttons visible (keyboard layout plus shift copies so that both can always be visible and work properly when releasing shift before the bind).

Whenever the character starts moving, GetItemInfo is called a ridiculous number of times, causing frame drops. This is Neuron. When I disable Neuron, the issue goes away.

I used FunctionProfiler and eventtrace to figure this out.

Hrm interesting... And only when you are moving? This intrigues me

It happens whenever I start moving. I see a flood of "GET_ITEM_INFO_RECEIVED" events and GetItemInfo is called too many times. Everything else in my UI runs smoothly except this.

Can you link to those two tools you used?

FunctionProfiler is here; old, but works just fine because it's not really affected by WoW API changes: https://wow.curseforge.com/projects/fprof

eventtrace is a built-in WoW debugging feature. Just type /eventtrace, then /eventtrace start or /eventtrace stop to start or stop it.

I wish I had a better function debugging tool that could show what called those heavy functions. I started trying to add that functionality to FunctionProfiler, but never finished.

Oh nice, I didn't know about that.

Question, are you making use of flyout buttons? Second, does the version in the master branch do anything to help? I looked at all our usages of GetItemInfo, and none of them looked suspicious. And I have no idea why it would be only when you are moving.

Ok I found the main source of this problem was a misfiring PET_JOURNAL_LIST_UPDATE that appears fully broken in the game. This even is firing each and every frame, which is definitely a bug. This doesn't solve 'all' the GetItemInfo issues, but most of those can only be solved by implementing some sort of a wait queue, instead of sledgehammering the game all at once with all of the events

It's not when I'm moving. It's when I start moving. It's not continuously while moving. Each time I start moving, a ton of events are dumped, causing some frames to be dropped.

Nothing seemed to change for me with this issue with the latest version, unfortunately.

I noticed that every time I start moving, my shaman buff for standing still goes away. Could this have anything to do with that, even though the buff isn't due to an item?

I deleted all the GetItemInfo calls that are in if checks and the lag went away. Of course, buttons where the item cache doesn't contain the item, such as a Hearthstone macro on a new character, don't appear, but my existing characters' buttons all work nicely and since there's no more spiky lag, this is better for me for now. I can put them back on a new character, set up my bars, and remove them again. It's a hassle, but better than being lagged all the time during normal gameplay.

Maybe with this clue, this can be fixed by only adding items to the cache only on login and placing/editing a macro.

How is it now in the latest release?

Unfortunately, I still get a flood of GET_ITEM_INFO_RECEIVED every time I start or stop moving and a couple frames are dropped with that version. I don't with my own version, but my version has laggy SPELL_UPDATE_USABLE events with 124 handlers, while your version doesn't lag on the SPELL_UPDATE_USABLE event, with only 12 handlers. It's the flood of GetItemInfo calls lagging instead.

Damn, well there's only 1 GetItemInfo call that's left in that file (there's 2 others but they only fire when dragging a spell). I was hoping that by putting the conditional check AFTER the ItemCache check we could avoid the whole GetItemInfo reauest entirely. However it seems lua doesn't check if conditions in sequence, and processes them all regardless. Ugh.

Ok I moved the GetItemInfo call to the MACRO_PlaceItem function, thus it will check if the item is in the ItemCache upon placing. This takes it out of the MACRO_UpdateData, and should solve the problem for good. Can you check the latest MASTER and tell me if it fixes it for you?

No, that didn't work. It's similar to something I was trying earlier today, but after I started to understand the logic of this whole thing, I realized that the only way to fix it is with some pretty major changes involving ensuring the right events are registered by the right types of buttons. I made those changes and it now works beautifully for me. I'm going to submit a pull request with those changes shortly.

OK, I've submitted #158

OK, that pull request was merged and this is now fixed. Thanks!

I made a few changes to your patch after merging it, notable in the OnShow and OnHide events. The rest was just updating your patch to the changes I had made since you based your branch.

Can you test my changes to see if they mess you up at all?

Can you also do me a favor and sort through the remaining register events in the OnShow and OnHide, and add those to the RegisterCorrectEvents. I want to avoid having events registered and unregistered in many separate locations to I can keep track of all this lol

As you could see with the piling up issues, u had to revert back. I've saved all of our work on a new branch. Let's work there and get it perfect and then telease it in one go. I jumped the shark and released it way too soon, but, hell, I was excited