Performance code change?

1 view
Skip to first unread message

Cosmic Cleric

unread,
Jan 1, 2008, 5:03:16 PM1/1/08
to develop_xub
Hey guys. I made this change to the PerfectRaid button support...

elseif ( XUB_UF_RaidFrames == "PerfectRaid" ) then
for g=1,4 do
for u=1,40 do
test = "PRHeader" .. g .. "UnitButton" .. u;
if ( getglobal(test) ~= nil ) then
if ( getglobal(test).unit ~= nil ) then
if ( XUB_RaidTable[getglobal(test).unit] ~=
nil ) then
XUB_RaidTable[getglobal(test).unit] =
XUB_RaidTable[getglobal(test).unit] .. "/" .. test;
else
XUB_RaidTable[getglobal(test).unit] =
test;
end
end
else
break
end
end
end
elseif ( XUB_UF_RaidFrames == "PitBull" ) then

Basically I added the "break" and the end of the if block. No reason
why we should continue looping ghrough all 40 entries for a 10-person
raid, etc.

It seems to help performance some. I guess fewer calls to getglobal
helps.

Does this change seem beneficial to you all? Should it also be
applied to the other raid add-on type code blocks above the
PerfectRaid one?

Drome

unread,
Jan 2, 2008, 10:24:35 AM1/2/08
to develop_xub
It may be.

The only option is to try it and see how it works. I haven't looked
at the PerfectRaid code so I don't know if this would cause a
problem. The assumption that this tries to take advantage of is:
Once I see a nill unit frame in a group there will be no more unit
frames in that group so we can move on to the next group. IT seems
very reasonable.

Cosmic Cleric

unread,
Jan 3, 2008, 8:05:09 PM1/3/08
to develop_xub
I checked into my "CosmicCleric" branch the changes I described
above. I've been using this changed code, and the lagging has
diminished, but still exists.

For what its worth, the lagging seems to be a problem once there is
more than ten members in a raid.

Its still a problem, but a little bit less of one.

BTW, a new version of PerfectRaid is out, and I have been using that
one.
Reply all
Reply to author
Forward
0 new messages