OnUpdate efficiency

[Haleth]

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!

[Vlad]

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!

[Barjack]

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.

[Haleth]

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.

[Barjack]

Originally Posted by Haleth 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.

That's how I was assuming the single-OnUpdate version would work, yeah. Something like

function someUpdateChecker (self, elapsed)
  local timer1 = timer1 + elapsed
  local timer2 = timer2 + elapsed
  if timer1 > limit1 then
    timer1 = 0
    doStuff1()
  end
  if timer2 > limit2 then
    timer2 = 0
    doStuff2()
  end
end

Which is what I assume is more efficient than a 3-function (or 2-function in this simplified example) alternative simply because it essentially is 3 different update functions, just all crammed into one. Perhaps you had something else in mind, though.

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.

[Nimhfree]

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.