Question regarding Table size & CPU cycles

[Lysiander]

Hello,

I have a question just how much I should worry about CPU efficiency. I wrote a modified version of the oUF_raidfilter pluggin (rewrote really, learning experience). Basically, I hooked the UnitAura event to my raidframes and have it check for the presence of certain debuffs. Since the table of debuffs is rather larger (300+ entries) I decided to structure it by zone and have it check if I am in a zone that actually has entries first and let the function jump to that section.

Here's the real question. I am not iterating over the table, so "i think" all the function does is check if a specific entry is there. How does WoW or lua work in that regard, does it internally iterate over the table until it finds an entry or does it simply check once if there is an entry?

In other words, does the size of the table actually matter or am a worrying needlessly? UnitAura gets called very often on raidframes in raids, so internal iteration could cause issues while a single check is just that.

Edit: On a sidenote, I have played around with combat log processing recently (dabbled really) and I wonder which one would be more efficient, using the unit UnitAura event to check if a debuff is present (afaik this means that every single raidmember executes the referenced function when it gains or looses a UnitAura) or to process the combat log for Spell_aura_applied, check if the spellID matches my table and then show a debuff icon on the return value of destGUID? UnitAura seems a lot more simple and elegant, but I don't know how up to 40 calls per event compare to combat log processing CPU wise.

[SDPhantom]

As far as table indexing, Lua uses a hash system that directly goes to the entry where the data is.

Now for the difference between processing UnitAura and CombatLog, I would favor CombatLog. Both of them would proc X amount of times for the number of people in your raid for the same buff. The only notable difference is with UnitAura, you'll need to call a function to check if the aura applied or fading is the one you're looking for. If you use CombatLog, the event fires with all the information given in the additional arguments, no need for additional calls.

[Phanx]

Originally Posted by Lysiander ... I decided to structure it by zone and have it check if I am in a zone that actually has entries first and let the function jump to that section.

If you're doing that check inline (eg. each time the function runs, it looks up your current zone and then looks for the same-named subtable), you should move it to a separate function that only runs when your zone actually changes, and updates an upvalue to point to the relevant subtable, which you can then access much faster in your aura event handler.

[Lysiander]

@Phanx
That is what I did. My oUF checks for the WORLD_MAP_UPDATE event and then populates a table based on the current zone and the return of the GetMapInfo() function. This causes some trouble because when you reload the UI or sometimes while zoning, the GetMapInfo() function returns nothing at the point WORLD_MAP_UPDATE is fired due to the player being in a voidspace. Frankly, I have found this unreliable so far.

@SDPhantom

Thanks for the info. You make a good point about the combat log, but I still have a question there. I have tried working with the combat log in oUF, which works fine for the most part, but only if I hook the event to every unitbutton there is. (when relevant of course, party and/or raid) Basically that means COMBAT_LOG_EVENT_UNFILTERED is called up to 40 times, once for each unit, when once would suffice.

So I am looking for input on my idea to reduce this to one functuon calll per actual event. Basically I want to do is this (pseud code)

create an empty reference table

function called by oUF for every unitbutton(raid & party)
create frames to show stuff
populate a table with frame and unit references
end

update function called on event
if relevant combat log happened then
check if unit is present on the reference table, get frame reference
do stuff to frame reference
end

create frame
register event (combat log)
call update function

In theory, this should work, or at least looks solid to my eyes, Im just wondering if there is possibly an easier way to acomplish having the combat log event happen only once.

alternatively, I could just add two lines to the update function call, one variable that equals the events timestamp and another to end the function if the checked timestamp is equal to the variable. (reversed in the code of course) But this might kill events that happen at the same time. Could just use all combat log data though. That should be unique. Im just thinking out loud at this point, so i'll stop.

This is in the same vein of the original questions, do I actually need to worry about this CPU wise? There will be a difference, but the question is, is the difference big enough to waste time on.

[SDPhantom]

Originally Posted by Lysiander @SDPhantom Thanks for the info. You make a good point about the combat log, but I still have a question there. I have tried working with the combat log in oUF, which works fine for the most part, but only if I hook the event to every unitbutton there is. (when relevant of course, party and/or raid) Basically that means COMBAT_LOG_EVENT_UNFILTERED is called up to 40 times, once for each unit, when once would suffice.

What you could do is build a table with GUID-to-UnitButton mapping and have just one frame handle the event. This way when COMBAT_LOG_EVENT_UNFILTERED fires for X player, the frame will have Y UnitButton update.

[Lysiander]

Sorry for not posting. I had a busy weekend and the weeks not looking any better so far.

@SDPhantom: That was basically what I meant with my pseudo code, sorry if that was unclear. I'll take your suggestion as confirmation that this should work and will try it out when I find the time.

[Lysiander]

Well, I gave it a shot, but ultimately I am not saving anything noticable by using the combatlog for this. I successfully managed to cut it down to one function call per combat log event, but I hit a brick wall when it comes to my priority system. Since the logic of my pluggin is based in prioritizing buffs and debuffs over one another, I'd have to run a UnitAura check to see if any lower or higher priority buffs/debuffs are present. Since eliminating UnitAura as a check was the goal, this kind of defeats the purpose of using the combat log.

I opted to filter out anything that has a duration of 0 and some of the standart buffs to cut down cycles, which reduces the amount of checks made and seems to work fine so far.

Thanks for your help on this you two. Its been an interesting learning experience.