InitializeXUB_UnitList() called twice inside of XUB_ApplyProfile
0 views
Skip to first unread message
Cosmic Cleric
Dec 20, 2007, 5:10:21 PM12/20/07
to develop_xub
I noticed that the fuction InitializeXUB_UnitList() gets called twice
inside of function XUB_ApplyProfile, lines 692 and 706. I was
wondering why, and if both calls are needed?
Trying to do some profiling to get the performance problems down for
raid support.
inside of function XUB_ApplyProfile, lines 692 and 706. I was
wondering why, and if both calls are needed?
Trying to do some profiling to get the performance problems down for
raid support.
Drome
Dec 21, 2007, 6:15:08 PM12/21/07
to develop_xub
Looking at it I would guess teh second could be removed. Comment it
out and see what happens.
Drome
out and see what happens.
Drome
Tayedaen
Dec 22, 2007, 5:06:38 AM12/22/07
to develop_xub
I did that long time ago when I started to learn E.'s code.
Ot didn't work, and my understanding of the code was not good enough
at that time to understand WHY.
Perhaps it will work now, but I doubt it.
cu
tay
Ot didn't work, and my understanding of the code was not good enough
at that time to understand WHY.
Perhaps it will work now, but I doubt it.
cu
tay
Cosmic Cleric
Dec 22, 2007, 6:02:00 AM12/22/07
to develop_xub
I tried Tay's suggestion and REMmed it out (the second one), and
didn't see any adverse side effects. Been in BGs with it for three
days and didn't see anything 'wrong' come up, so probably safe to
remove.
I'm hoping we'll be able to visit this code in the future and try to
rework it so it doesn't always completely destroy and rebuild every
button, every time there's a raid change? If you're in a 10 to 25
person raid and one person leaves, it would be nice if the code could
figure out who left and remove those buttons only, and when a new
person joins only adds the buttons for the new person, instead of
rebuilding the buttons for all people each time.
After removing the forced garbage collection function call, the only
performance problem I can still see is from the wholesale destroying/
rebuilding of all buttons for small raid changes. Very painful when
you have a couple of people leave/join a raid in a small point of time
(happens in BGs all the time when people hop from WSG to AB to AV,
etc.).
didn't see any adverse side effects. Been in BGs with it for three
days and didn't see anything 'wrong' come up, so probably safe to
remove.
I'm hoping we'll be able to visit this code in the future and try to
rework it so it doesn't always completely destroy and rebuild every
button, every time there's a raid change? If you're in a 10 to 25
person raid and one person leaves, it would be nice if the code could
figure out who left and remove those buttons only, and when a new
person joins only adds the buttons for the new person, instead of
rebuilding the buttons for all people each time.
After removing the forced garbage collection function call, the only
performance problem I can still see is from the wholesale destroying/
rebuilding of all buttons for small raid changes. Very painful when
you have a couple of people leave/join a raid in a small point of time
(happens in BGs all the time when people hop from WSG to AB to AV,
etc.).
Drome
Dec 24, 2007, 9:43:00 AM12/24/07
to develop_xub
That would help a lot. It is interesting - that is one of the things
that PitBull does. It doesn't destroy a frame immediately - but
places it in a list for reuse. If XUB it could be something like
XUB_GetButton() and XUB_ReleaseButton(mybutton). Get buttons looks
for a released button and if not found creates one and Release Button
clears its state and adds it to an XUB_AvailibleButton table.
Drome
that PitBull does. It doesn't destroy a frame immediately - but
places it in a list for reuse. If XUB it could be something like
XUB_GetButton() and XUB_ReleaseButton(mybutton). Get buttons looks
for a released button and if not found creates one and Release Button
clears its state and adds it to an XUB_AvailibleButton table.
Drome
Reply all
Reply to author
Forward
0 new messages