Accumulation of Lag

[CodingDino]

It's rearing it's nasty, nasty head again. I was thinking that curse user who reported this was just being silly, but after using the addon for an extended period of time on the Beta, it's definitely happening - much more slowly than before, and seemingly not a result of scrolling.

It's very possible it's due to something in the recorder, too, since I had that running as well. Basically every time the recorder recorded a new step, and the step was subsequently checked off, there was a tiny tiny tiny bit more lag. It wasn't noticeable until after something like 50 or so steps, but it eventually did become a problem.

Hopefully in the midst of the clean up Silvann and I are doing to the code, this will get fixed, but I wanted to fully report what I experienced with it so we would know.

[silvann]

Hmm, I only noticed a "non-real" memory leak. It's actually a increasing garbage memory, but that's freed from time to time, so it shouldnt really be an issue. Other than that, it's been a while I dont play, but I was not getting increasing lag.

And to be honest, I havent played with or read the Recorder code. :p

[CodingDino]

Yeah, it's quite possibly in the recorder and NOT in the normal guide, which honestly, is okay with me. I don't want to put our normal users through annoyances like this, but people working on the addon know that recorder is still kind of experimental and I think they'll be okay with it until I can track it down.

[CodingDino]

Note: this may have something to do with sticky steps, as the lag seems greater when several of them appear together.

One scroll through my entire Desolace guide generated an additional 0.3 MB of memory. Also occasionally caused a crash. Nasty :(

[CodingDino]

Yuck. Every page I scroll down now seems to generate about 0.1 MB. But it seems to be temporary. Hmmm, perhaps the garbage collector is just slow?

EDIT: Now that's just weird. The used memory doesn't go down on it's own, but when I alt+tab it returns to it's initial total (of a little under 1 MB)

[silvann]

Yeah, that's the "non-real" memory leak I noticed. I dunno much about garbage collector in Lua, but I think it is called when garbage memory reaches a certain value or by time passed. But instead of trying to call garbage collector more often, I think we can decrease the garbage. If I had to guess, I'd say the problem is the row dropdown, where the dropdown frame/buttons get generated in every UpdateGuide. I was supposed to test this, but didn't have time. >.>

[CodingDino]

Hmmm, that would make sense. But yeah, over time the memory does reduce itself back down to about 1 MB.

I'm not very familiar with easymenu, is there an easy way to simply update those frames instead of re-creating them?

[silvann]

Sort of. I found a better way when I was checking TomTom dropdown callback funtions, but it looked more complicated at first. My idea was to learn/test this other method when implementing dropdown options on the dungeons list frame, but I dunno when I'll have time for that now. >.<

[CodingDino]

A note - I made some changes last night to how the dropdown lists were handled. The core broker now handles the frames and the easymenu call, while the table is created in the specific addon. I did this both to limit copy/paste code and to allow the Recorder to hyjack the left-click function and dropdown menu for steps. I'm working on adding some new functionality to the recorder :)

[CodingDino]

Added some checks to make sure the addon isn't trying to complete steps a million times (it seems to have been doing that lately). Hopefully that will help some.

[brandonh6k]

From the wow-pro bugs page:

Hi,

First of all, I just wanted to say that I really appreciate the efforts put into the wow-pro family of addons, and would like to start contributing to the development process as soon as I understand how a WoW addon is written.

I've been using the addon for a while now, and have noticed an increase in lag ever since Cataclysm (4.0.1) went online. I've tried isolating the problem to a specific module, and it seems to me as if the problem is not in the general Wow-Pro module, but in the leveling module itself - when unloading this module, I get consistently higher responses from the server (~100 ms compared to 1000+ ms with the module). Any way I can find a log to help debug this?

Thanks, Jon

[CodingDino]

This seems to be a persisting problem for people, though I've gotten rid of all the taint issues and redundant step completion I can find. Anyone have any more ideas on how to reduce our lag issues?

[luis-ortiz]

Hmmm, I just noticed this problem myself. Performance problems are quite vexing. I see there is an API for monitoring AddOn CPU and memory usage.

I'll do a quicky performance monitor and see if the leveling module really is the cause of the problem, or if it is tickling some other component that is really the root cause (like the arrow).

[silvann]

I still think the problem lies on creating dropdown frames every time there's a guide update (even just scrolling). I read somewhere that after creating frames, you can't delete them or rely on the garbage collector. Those memory are still considered in use. There's a more lenghty way to deal with dropdowns dinamically, but I never got to that. >.<

[luis-ortiz]

If the problem were GC or memory related, I would expect to see bursty increases in the CPU consumed by the addon. If the problem get worse over time or when more frames are displayed, then I would worry about even processing occurring on active or even (G-d forbid) on frames we think are gone.

Oh the horrible problems I have caused with OnUpdate scripts!

I read a reference in "Beginning Lua with World of Warcraft Add-Ons" by Paul Emmerich that said: "There is no way to delete an existing frame (the garbage collector cannot delete frames) so it is a good idea to reuse it." . Is that what you recall, Silvann?

[silvann]

Yes! At any rate, that's the only idea I got about it.

[luis-ortiz]

Ugg, I looked at WoW_Interface_enUS/FrameXML/RestrictedFrames.lua and looked for uses of the function GetChildren(), which returns the child frames of a given frame.

I saw things like ChildUpdate_Helper(env, self, snippetid, message, frame:GetChildren());, which means that key clicks, events and other things have a linear dependence on the number of children. If we are constantly adding child frames to a given frame, then we are slowly growing the cost.

Worse yet, if those abandoned children, which are not garbage collected because there is no way to unregister a frame from its parent (no child abandonment), could still be registered for processing events and slowly increase the amount of processing occurring.

The code for doing cached CreateFrames is not complicated and has been implemented in a dozen ways. I'll also a debug print to see if the number of children of WoWPro.MainFrame, or WoWPro.GuideFrame is growing, to confirm this problem before doing any surgery.

[luis-ortiz]

Hmm, this popped up recently:

http://wow.curseforge.com/addons/tomtom/tickets/16-slow-down-low-fps-when-crossing-of-zone-border-some/

[luis-ortiz]

So as of the 2.1.14 release with TomTom 1.4.0 my FPS drops are gone. Anyone else seeing what I am seeing?

[luis-ortiz]

Closing because the badness went away :-).