OnUpdate efficiency
Hello!
I use an OnUpdate script to display fps/latency/hour+minutes in my UI. It updates every second, mainly for the fps. I was wondering though. Considering latency is only updated every 10 seconds, and there is no use in getting for the time every second when it only updates every minute, would it be more efficient to use 3 separate OnUpdate loops - one which updates the hour/minute value every 30 secs, one which updates the latency every 10 secs, and one which handles the fps as well as displaying the other values - or should I stick to just 1? The difference is minimal, of course, it's mostly a matter of principle. Thanks! |
So either one update that runs a function or two updates running two separate functions, good question.
Oh, I just wish you could make onupdate scripts and specify the update interval when you set the script on the widget, think it would be more performance friendly like in scenarios like this yes? Having a bunch of variables to count in order to track the time elapsed, too many of those and you get impact on performance... oh sorry off topic! |
My intuition would be that function call overhead makes a single OnUpdate function (marginally) more efficient--though I haven't actually tested this.
But since OnUpdate scripts on visible frames are called once per frame regardless of whether or not your condition in that function evaluates true or false, the result in either case is 3 mathematical operations per frame (adding time elapsed to a "time since last update" for each type of thing), 3 comparisons per frame (comparing total time elapsed against your delay for that type), but 1-3 function calls per frame depending on the number of functions you're using. Again though, this is all just assumptions on my part. I've not actually benchmarked the difference and there may very well be considerations I'm overlooking. And if frames are ever being hidden and their OnUpdate scripts therefore skipped, that may make a difference as well. |
I had an idea, not sure why I didn't think of this before - and I think it is what Barjack means also - it would be possible to use 3 different 'time since last update' values, check for each in one OnUpdate script and let them count to different numbers. That might be the most efficient, unless conditions actually require more instructions than a simple time/latency check.
|
Quote:
Code:
function someUpdateChecker (self, elapsed) Naturally, as you said in the original post, the difference is probably undetectably minor. In fact, I wouldn't be surprised to learn that the speed of whatever has to manage SetScript callbacks etc. is slower than the actual difference here and therefore results in a slightly bigger difference overall. Again, all completely untested etc. |
My first assumption is that you should code everything up in just one. Ignore the timing of FPS and the actual clock and just update all of them each time you decide to do work in your OnUpdate script. If that works well and does not slow things down you are fine. If you are really worried about it, you can time the individual calls and determine if their overhead is worth the mathematical comparisons needed to control accessing them.
|
Thanks for the insight everyone, worth a read :)
I figured that a time lookup would be too light to put in a condition and give its own counter. I just update that every second. I did give latency its own update frequency though. Code:
local _, _, home, world = GetNetStats() |
Latency only updates every 30 seconds (unless they changed it in 4.3). :) Best course of action is to do a fast timer (say every 3 seconds) until the Latency value updates, then start a timer every 30 seconds from that point. This way you get the latency value when it updates, and only when it updates.
|
Oh right, it somehow got into my head that it was 10. Thanks :)
|
AceTimer3.0 lets you set functions that are only runned in the seconds you specify
from wowace page: Code:
MyAddon = LibStub("AceAddon-3.0"):NewAddon("TimerTest", "AceTimer-3.0") Code:
MyAddon = LibStub("AceAddon-3.0"):NewAddon("TimerTest", "AceTimer-3.0") |
AceTimer-3.0 uses an OnUpdate internally so there's no magic sauce in ScheduleTimer :p
It does take the approach of using 1 frame with a single OnUpdate to run all those separate registered timers from different addons so that says something, but this is not an OnUpdate vs AceTimer thing it's OnUpdate vs OnUpdate. |
Same do the animation widgets.
Another funny thing. You can make yourself a timer based on the animation widget. Maybe not efficient but maybe more fun. :) lua Code:
Afaik Tuller tried that in some of his cooldown mods aswell. Internally the animation widget is using onUpdate aswell (I guess). You even have the option to repeat the animation forever. The thing is the CPU usage may fade but it is just transfered to Blizzard code by using the animation API. |
You don't actually need to specify a type for the animation:
lua Code:
|
Even better. :)
|
i personally prefer to let blizz do the loop:
Code:
local mapTimer = AnimTimerFrame:CreateAnimationGroup() |
That works if you always want to repeat the timer. It only adds one line to control it myself (the animationGroup:Play() call at the end of the OnFinished script) and lets the timer be used as a delay (eg. "do this once, 30 seconds from now") or to detect when something happens that can't reliably be detected via events (eg. "check every 1 second to see if I'm mounted, then stop checking once I am mounted"). Auto-looping may be simpler if you're simply replacing a throttled always-on OnUpdate, though.
|
So this thread is relevant to my interests. :)
Using animations instead of throttling OnUpdate seems to be a pretty straightforward way of reducing wasted cycles, since they are handled natively - not free, but faster in C. A example inspired by NPCScan would be lua Code:
Just what I needed. More things to putz with and change instead of working on what I need to =P |
Back when the Animation System was new, Shefki (PitBull4 maintainer) wrote LibShefkiTimer-1.0 as a drop-in replacement for AceTimer-3.0.
|
My concern would be the resource cost of adding 2 objects on top of the frame to handle it. The animation group and animation object per timer. It is unknown as to the actual impact on CPU usage between using OnUpdate timers and animation objects. Just because exposure to Lua code is reduced doesn't mean it's automatically faster. The C code could be running much more than just triggering an OnFinished script and that would take time too.
|
All times are GMT -6. The time now is 11:04 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI