[Mists][5.5.1] Raven's sprung a (memory)leak big fps issues

[Road-block]

Since the Mists Classic 5.5.1 patch "Landfall" I've been experiencing some - seemingly randomly occurring - stutters.
Since I've had this happen in the past and I recognized the signs of something hitting the garbage collector hard (causing the CPU spikes that affect the framerate) I installed an addon profiler and monitored memory usage for a while.

Static memory usage in addons is not an issue, in fact exchanging static memory for CPU is always good for the end user.

BUT, rapidly increasing memory usage that causes the garbage collector to fire repeatedly is really bad.
At the moment Raven seems to at times (idling in Shrine solo) start shooting up in memory consumption.

Shoots up to 200mb over the course of 40seconds to 1 min, garbage collector kicks in, drops to 8-9mb, rapidly increases to 200mb again and the cycle continues.
While this is happening the framerate keeps fluctuating wildly.

In raids the game becomes unplayable as the memory leak is much more rapid.
The apparent increase is at a rate of ~2mb/second but that's a mirage as there's gc cycles happening before the big one at 200mb.

This is what it looks like before the big GC happens. As you can see there's other addons listed with fairly high mem usage but they are static.

Drops to this after big gc happens and keeps yoyo-ing between the two extremes.

[Road-block]

To make sure Raven is not getting saddled with some embedded library baggage, I unloaded the addon and monitored memory anew.

If it wasn't a Raven issue, I'd see a different addon using ever increasing memory and hitting GC.
That did not happen, so I have to conclude Raven is the one leaking.

[Road-block]

My two PRs are not relevant to this issue.

They're meant to fix other problems that I stumbled upon while familiarizing myself with the code and looking for obvious memory leaks.
With the changes in place Raven is still churning memory at a rapid pace.

Some module or modules are creating tables or closures en masse, and discarding their references but I haven't identified the relevant codepaths yet.

[Road-block]

This older issue #102 seems relevant.
I don't think this is a recent change in Raven, we notice it more now in Mists Classic probably because they did something with the client and how aggressive it is with GC in the 5.5.1 patch would be my guess.

[Dicebar]

I've been looking at this one for a few hours now. The provided info was very helpful, thank you.

While I can replicate the problem – Raven leaks about 400kb/s for me while idling – I haven't been able to find the actual source.

For me personally, the secure in-combat bar leaks about 300kb/s while idling. It's something I can test with and focus on, but it doesn't use any caching or iteration at all as far as I can tell (outside if initial setup). To my (incomplete) knowledge of how the code works, it just tells WoW which buffs to look for and where to position their icons. And this leak happens even when the list of buffs is empty.

That is not to say that the in-combat bar is the problem, because on an empty profile with zero bars, the addon still leaks. The problem seems systemic to all parts of Raven.

But some of it is definitely simply WoW itself. For example, disabling all code in the addon and re-enabling everything step-by-step led me to finding out that calling C_Timer.NewTicker() with an empty function leaks literally every tick. That was the first point where the addon started leaking.

I wouldn't be surprised if the way Raven handles caching contributes to the problem. But I also wouldn't be surprised if Blizzard introduced a bug that leads to local variables within functions surviving out of scope.

All that is to say... I'm not sure how to even approach this problem at the moment without resorting to reassembling the addon line-by-line. I'd prefer a more efficient approach, so I'm gonna let this one percolate for now.

[Road-block]

so I'm gonna let this one percolate for now.

Yep
I let this issue marinate as I also did some profiling and couldn't find any "obvious" spots.
I made a method in my local copy that I could wrap a method in that does a memory and computational time calculation and looking at various parts of the mainloop + the spammier events (unit_aura, cleu etc) but while I did spot some places, resolution is not obvious.

I'll keep tinkering, maybe inspiration will strike. But also with the catastrophic changes coming with 12.0 (I don't play mainline myself but still) I don't think it's a good time investment to be going on big refactors.

PS. I did the profiling through debugprofilestop() for computational time and a combination of collectgarbage("stop") > collectgarbage("count") (at invocation and another at return of a method) and collectgarbage("restart") to get some reads on computational time and memory consumption for specific codepaths.

The in-combat bar having steady churn though is a good spot, I'll look at that more closely when I find some time.

[Road-block]

About the ticker thing, that is expected if you feed it an anonymous function as it creates a new closure every tick.

It's one of the reasons I changed the mainloop to a ticker with a passed in function reference, instead of an .After call with an anonymous one that was repeatedly calling itself every frame.

[Dicebar]

About the ticker thing, that is expected if you feed it an anonymous function as it creates a new closure every tick.

It's one of the reasons I changed the mainloop to a ticker with a passed in function reference, instead of an .After call with an anonymous one that was repeatedly calling itself every frame.

I actually used that very ticker, I just cleaned out the contents of the function. It wasn't an anonymous function.

[Road-block]

Hmm, that sounds like some blizzard f*ckery then.