Texture:SetWidth or Statusbar:SetValue

[sirann]

For a castbar, something that's getting updated OnUpdate during a cast essentially, would it be more cpu efficient to have the actual variable length bar that represents the cast length be a statusbar or a texture?

[Duugu]

Originally Posted by sirann For a castbar, something that's getting updated OnUpdate during a cast essentially, would it be more cpu efficient to have the actual variable length bar that represents the cast length be a statusbar or a texture?

I would say if this is just about the texture it doesn't matter that much at all, as the Statusbar widget does use a texture (BarTexture) to draw the filled part of the bar too.

A better approach to enhance the performance could be to restrict the updates to situations where there actually IS any update to draw. For example: if your castbar has a width of 100 points, and you would like to show a duration of 200 seconds, then it doesn't make much sense to set up the bar on every second as 199 and 198 seconds remaing would both be equal to 99 points.

[e]
My guess is that a Statusbar actually is slower. There must be some overhead with SetValue and such stuff.
But, I did no tests or such things. So, don't nail me down on it.

[Duugu]

Ok, I did some quick tests, and the findings are that doing

for x = 1, 1000000 do
    sometexture:SetWidth(x/10000)
end

takes 129.82 ms cpu time and

for x = 1, 1000000 do
    somestatusbar:SetValue(x/10000)
end

takes 105.83 ms cpu time.

That's a surprise. The c side implementation of SetValue seems to be much faster than SetWidth.

But, seeing those (ehm ... is it 'these' or 'those' in this case? ) results, I would guess it doesn't matter much which approach you're using as long as you don't have A LOT OF castbars.

[sirann]

Heh, thanks for the very thorough experimentation! PS, how did you measure the cpu usage? an addon profiler?

[Seerah]

You just call GetTime() before and after and compare the results.

[Gello]

I recommend debugprofilestop().

When comparing the relative "cost" of a function, I'll often do:

local t = debugprofilestop()
for i=1,10000 do
  -- function you want to time
end
print(debugprofilestop()-t)

This will perform the action 10000 times and tell you how long it took to do it.

But you also want to be thorough in your testing. It's possible that a SetWidth to a texture that's already at that width is not computationally expensive at all. So it's good to set up tests where the function will be run differently. Such as:

local t = debugprofilestop()
for i=1,10000 do
  texture:SetWidth(i%100+1)
end
print(debugprofilestop()-t)

Running the test with i%100+1 and a static value like 100 will tell you if SetWidth takes the same relative time to set the same width vs varying widths.

[Duugu]

Originally Posted by sirann Heh, thanks for the very thorough experimentation! PS, how did you measure the cpu usage? an addon profiler?

I'm using GetFunctionCPUUsage().

I know it's not exact and such ... but to compare the costs of something it's as good as the other ways. And it counts the calls.

[Phanx]

Originally Posted by Duugu That's a surprise. The c side implementation of SetValue seems to be much faster than SetWidth.

Not really surprising, but also keep in mind that SetValue does more than just pass the value to SetWidth, as it has to calculate the correct width based on the specified value relative to the min/max values and the total width of the frame. Even if you're storing those other values in upvalues, a non-StatusBar implementation of SetValue would have to do this:

texture:SetWidth((value - value_min) / (value_max - value_min) * frame_width)

...which would obviously be even slower.

Originally Posted by Duugu I would guess it doesn't matter much which approach you're using as long as you don't have A LOT OF castbars.

Just use a StatusBar object. It's much less work to work with.

[SDPhantom]

Originally Posted by Gello I recommend debugprofilestop(). When comparing the relative "cost" of a function, I'll often do: local t = debugprofilestop() for i=1,10000 do -- function you want to time end print(debugprofilestop()-t)

I usually start out the code with debugprofilestart(). What debugprofilestop() does is act as an interface to the C function GetTickCount() and internally subtracts the same value associated with when debugprofilestart() was last called. Since this is in C code, it's usually best to use it instead of running it through the Lua interpreter.

debugprofilestart()
for i=1,10000 do
-- function you want to time
end
print(debugprofilestop())

[sirann]

I appreciate the multi-faceted array of answers. I suppose now to follow-up, the new C_Timer being given to us. Will use of this to update "bar" type addons such as buffbars and castbars be of cpu performance importance, or simply a coding quality of life addition?

[semlar]

You can't really use timer functions to update things like a castbar because the state of a cast can change (pushback, interrupts, etc.) and you want it updating its display every frame anyway.

Frankly it doesn't make enough of a difference in CPU usage to make it worth optimizing for, either.

[sirann]

Exactly what I was inquiring. Thank you all!