Changes in Raid and performance

[Tayedaen]

Hi!

I rewrote a lot of code to improve performance.
But I've found out that there is not "the best way" to do it.

Let me try to explain:
Till now (beta 7 and older) we are recreating the buttons for ALL
raidmembers if we detect a change in the raid by the event
"RAID_ROSTER_CHANGED"
This is potentially an overkill, since there is probably only one
single member that got added.
So I wrote code that recreates the buttons only for those members that
changed.

But these additional checks take some time for processing, so they
create an overhead.
So while the code improves the perfomance for 40 members, it could
(potentially) make it worse for 10 members.
Now we have to find kind of a "sweet spot".

I'll show you some code so you can see what it did ( or at leat tried
to do).

[Tayedaen]

All code that I am going to show is from the function XUB_OnUpdate.
Inside this function, there is a section that is only run through if
XUB_APPLY_DEALY was set somwhere else.
Most of the time XUB_APPLY_DELAY is set when a party/raid changes.
So this is the code that runs when a part or raid change is detected.

[Tayedaen]

Code from 1.9 beta 7:

Most of the code lines below are BULLSHIT ;-)))
All the code does is: it performs the first IF check, applies the
profile (=recreates all buttons) and then returns.
All other checks below are never run though, making the code obsolete.
I am not sure who made that stupid mistake, but I fear it was
me ;-))))

Code:
if ( XUB_GroupRaidChange ) then
XUB_GroupRaidChange = nil;
XUB_ApplyProfile(XUB_CurrentProfile);
return;
end

if ( GetNumRaidMembers() == 0 ) then
for i=1,GetNumPartyMembers() do
lName = UnitName("party" .. i);
CurrentMembers[i] = lName;
end
else
for i=1,GetNumRaidMembers() do
lName = UnitName("raid" .. i );
CurrentMembers[i] = lName;
end
end

if ( #CurrentMembers ~= #XUB_PlayerPartyUnits ) then
XUB_PlayerPartyUnits = CurrentMembers;
XUB_ApplyProfile(XUB_CurrentProfile);
return;
end

for i=1,#CurrentMembers do
if ( CurrentMembers[i] ~= XUB_PlayerPartyUnits[i] )
then
XUB_PlayerPartyUnits = CurrentMembers;
XUB_ApplyProfile(XUB_CurrentProfile);
return;
end
end

[Drome]

One of the things you mentioned on WoWInterface is the different
cases. To expound a little:

Spell with no Buff or Debuff (Heal)
Spell with Buff - non - stacking (Blessing of Wisdom)
Spell with buff stacking (renew)
Spell with Debuff non stacking (IE the ones where isspellusable is
broken - PowerWord shield, Divine Protection etc)
Spell with Debuff stacking (not sure there is such a thing).

I think you hit it right on the head in that we should support these
independently and the place to do it is in a ui. The issue is that we
want to avoid impacting existing users if at all possible. This
implies that the default behavior is to treat a button as a non-
stacking buff with the buff name the same as the spell (IE dims if the
buff is on the player). We add a new custom button type called
SimpleCast that avoids the buff checking altogether. IF you have
performance problems in large raids you can convert from the default
behavior by creating a custom button of type Simple cast.

Added extras could be:

Maintain a list of spells and what their default behavior should be.
Add in logic to maintain the stacking buff spells i have cast (perhaps
this is already covered in the is spell usable function)
Add a ui to hide the generic creation of button / groups / profiles
(need to find a developer who can do this).

Drome

[Drome]

It was most likely me.

The initial XUB_GroupRaidChange was done to support Pitbull raid
frames. I am not sure why we set it on PARTY_MEMBERS_CHANGED but I
would assume that it was in response to a related pitbull problem. E
didn't want to to put related addon custom coding inline (IF If
PitBull then) which would be the most straightforward solution. I
think it may be time to remove pitbull support altogether. The
PitbullFrameNames approach has mostly worked for me (that is what I
have been using in my branch). I will spend some time to clean it up.

[Tayedaen]

You are right on the spot, and your thoughts are highly welcome.
I will think on a way to get there ;-)
I really like the simplecast idea.