Express a val from a local table as local?

[Aanson]

Hi there again.

All of my frames are contained within a table called 'Frames' which itself is in the addon table.

At the start of each of my modules, the table is declared as:

local f = V.Frames[module];    -- ie, in this case local f = V.Frames.Chat;

Whenever I'm writing functions though, I've always been in the habit of expressing each frame (which will be used within that function) as a local:

local cW = f.chatWindow;

I caught myself doing this 10 minutes ago, and now that I've got thinking about it, is it actually essential? The 'Frames' table (f) is already declared as a local after all. Should I just be using 'f.chatWindow' rather than 'cW'.

I know that each time I use f.chatWindow, it costs a local table lookup and that's what got me thinking. I'd much rather just reference each frame as f.xxxx to be honest, but I don't want to impact on performance unless said impact is infinitesimal.

I guess what I'm really asking is, does it make a big enough difference, performance-wise, to force me to declare them as locals as above?

Or does it really just depend on how many times I need to reference the frame in that particular function? For example, if I need to reference it 10/20/50 times, declare it as a local, whereas if it's just twice, don't bother?

Is the difference infinitesimal regardless of how many times the table value is called (within reason)?

Thank you again for any advice


Aanson.

EDIT: Spelling error.

[Barjack]

I'd say that thinking about how often that table lookup is happening is probably the best way to evaluate whether making a local is necessary or not (although even readability might be important). For something like a set-up function that runs once on PLAYER_ENTERING_WORLD, or something that happens when the player changes the settings on something, or does something infrequent like opening a bank or getting a whisper, I definitely don't think it matters. On the other hand, if that lookup has the potential to happen 10 times per function in a function that might happen 20 times per second during combat, then I personally would definitely consider making it local.

[Aanson]

Originally Posted by Barjack I'd say that thinking about how often that table lookup is happening is probably the best way to evaluate whether making a local is necessary or not (although even readability might be important). For something like a set-up function that runs once on PLAYER_ENTERING_WORLD, or something that happens when the player changes the settings on something, or does something infrequent like opening a bank or getting a whisper, I definitely don't think it matters. On the other hand, if that lookup has the potential to happen 10 times per function in a function that might happen 20 times per second during combat, then I personally would definitely consider making it local.

Yeah, that's perfect Barjack, thanks. That was pretty much the way my thinking was going. If it was OnUpdate, I'd define each frame from the table as a local at the start of the function without question, but for anything else that isn't used as often, it's not really all that important, unless I need to reference the frame a significant number of times (which never really happens).

Thanks again. I think I just needed reassurance

Aanson.

[Phanx]

Originally Posted by Barjack ... if that lookup has the potential to happen 10 times per function in a function that might happen 20 times per second during combat, then I personally would definitely consider making it local.

If you are looking up the same table value 200 times per second, or even calling the same function 20 times per second, in combat or nto, you are doing something horribly wrong.

Originally Posted by Aanson local cW = f.chatWindow

I'd really suggest avoiding cryptic variable names like cW outside of macros. Space is unlimited in addon code. Use names that (a) will immediately make sense to you if you don't look at the code for 6 months, and (b) will immediately make sense to other pgorammers looking at your code for the first time. There's just no reason to use something like cW -- where you have to try to figure it out from context, eg. seeing cW:AddMessage(...), or go find where it's defined -- instead of a descriptive name like chatWindow.

[Aanson]

Re the 10/20/50 look-ups in a func, I merely said that in the interests of creating a fictional scenario to express my point and, in turn, better ask my question. I assure you that I'n not ...

Originally Posted by Phanx doing something horribly wrong.

I'm disappointed that I mustn't have worded the question clearly enough to make that point obvious.

Originally Posted by Phanx I'd really suggest avoiding cryptic variable names like cW outside of macros. Space is unlimited in addon code. Use names that (a) will immediately make sense to you if you don't look at the code for 6 months, and (b) will immediately make sense to other pgorammers looking at your code for the first time. There's just no reason to use something like cW -- where you have to try to figure it out from context, eg. seeing cW:AddMessage(...), or go find where it's defined -- instead of a descriptive name like chatWindow.

With regards to the cryptic name cW; it's one frame of two within a small module called 'Chat'.

local cB = f.chatButton;
local cW = f.chatWindow;

Trust me, if you were to see it in context, I'm sure you'd be hard pressed at getting confused.

I'll keep it like that as it makes a world of sense to me, but thank's for your advice. Each to their own, I suppose.

Thanks, but for me, this question was already answered.


Aanson.

[Barjack]

Originally Posted by Phanx If you are looking up the same table value 200 times per second, or even calling the same function 20 times per second, in combat or nto, you are doing something horribly wrong.

How else do you expect I should update the timers on 20 buffs frames, for example, if not by allowing a function to be executed 20 times per second? I don't even want to think about how often ActionButton_OnUpdate is being called in the average UI, but it's probably more than 100 times even that amount.

[Phanx]

Why are you running identical OnUpdate scripts on 20 frames, instead of running one OnUpdate script on one frame that updates all 20 frames? The default UI is not exactly a paragon of good programming, so whatever it's doing is largely irrelevant, because you shouldn't be using it as an example of how to do anything.

[SDPhantom]

A grasp on reality. Any computer running 20+ FPS will be running OnUpdate scripts 20+ times a second by definition. We all know CombatLog events fire even more frequent than that at times. That's just to name some examples. This is the very reason we strive to keep as much major processing as possible out of such handlers.

[Barjack]

Originally Posted by Phanx Why are you running identical OnUpdate scripts on 20 frames, instead of running one OnUpdate script on one frame that updates all 20 frames? The default UI is not exactly a paragon of good programming, so whatever it's doing is largely irrelevant, because you shouldn't be using it as an example of how to do anything.

The savings of doing that are often negligible and can sometimes even be a performance loss when benchmarked due to table looping overhead. I only commented because I think your comment was absolutely ridiculous. But hey, let's go for another example. I have a total of five (wow, that's a lot) frames in my hypothetical UI, each of which track the duration of a debuff on my target or a buff on myself. I want the timers on them to be smooth and accurate, so I update the bars/timers on each of them four times per second (crazy, I know). Seems fine, right? But wait... five frames... updated four times per second... five times four... good lord, I'm calling the update function for these frames TWENTY TIMES A SECOND?! Something is clearly going horribly, horribly wrong here. What should I do, Phanx?

[Barjack]

Perhaps if we extract all logic from all of our functions, we can solve this problem. Take it all and move it into one gigantic, monolithic loop that runs... better be safe, and make it 19 times per second. Have it loop over tables and tables of frames, doing everything it can do to avoid calling functions. We will finally have achieved efficiency and programming excellence by minimizing the number of function calls we make per second. And as we survey the beast, our eyes can safely glaze over while scanning the contents of our inner loops, knowing that at least the code in that loop isn't in a function being called 20 times a second. Instead, it sits here, safely, in a loop that executes 20 times a se--oh... Oh no...!

[Phanx]

What are you even talking about? I stand by my original comment -- if you are performing the exact same table lookup 10 times in the same function, you are doing it wrong. You should perform the lookup once, store the resulting value in a variable, and use the variable 10 times instead. I have absolutely no idea how you jumped from that to multiple consecutive posts full of incoherent sarcastic rambling about... well, I don't even know what you were going for. Either you've had way too much caffeine, or not nearly enough.

[Barjack]

Do I need to quote your own post for you?

Originally Posted by Phanx If you are looking up the same table value 200 times per second, or even calling the same function 20 times per second, in combat or nto, you are doing something horribly wrong.

My buff/debuff frames are calling the same update function 4 times per second, and there are 5 of them. This means I am (quoting you again):

Originally Posted by Phanx calling the same function 20 times per second

and am therefore (again):

Originally Posted by Phanx doing something horribly wrong

I just want to know what I can do to avoid this situation. I know now that calling the same function 20 times per second is horribly wrong. The problem is I don't know what to do about it. How can I keep my addon's functionality here without doing this? How can I cut this number down? I was even thinking of adding a sixth debuff frame but doing so is almost unthinkable with how many more function calls it would add (at least 4 per second).

[Barjack]

Can you even imagine what would happen if I wanted to update my frames every 0.1 second to smooth the movement of the duration bar? That's 10 function calls PER FRAME, PER SECOND! And... ten times two is twenty, right? So even having a mere two frames in my entire addon would mean I'd be doing something horribly wrong.

[Aanson]

Originally Posted by Phanx What are you even talking about? I stand by my original comment -- if you are performing the exact same table lookup 10 times in the same function, you are doing it wrong. You should perform the lookup once, store the resulting value in a variable, and use the variable 10 times instead. I have absolutely no idea how you jumped from that to multiple consecutive posts full of incoherent sarcastic rambling about... well, I don't even know what you were going for. Either you've had way too much caffeine, or not nearly enough.

Phanx, I don't know if you've realized, as I'm unsure if it's intentional, but some of your comments can be needlessly nippy and sometimes even a little offensive. I'm not at all surprised that people will get a little defensive as a result.

I, myself, have found in the past that I want to intentionally leave as much detail out as possible when asking a question because I fear that things completely unrelated to my question will be flamed.

Your remarks on how I chose to define a frame is a perfect example of this.

All I'm saying is, if you choose to comment on something, sometimes it could be worded a little better.

I'll understand if, due to these comments, you choose not to answer any question I might ask in the future, and if that is the case, I am worse off for it, but thanks for the help in the past because it genuinely was invaluable.

But I won't be commenting on this topic (or subject) again.


Aanson

[SDPhantom]

Phanx has been known to have a stick up his ass on some things, but at times, does make valid points. This entire topic is really a judgement call on how many indexing operations are made overall. While function calls do have an impact on CPU usage, so does executing any code in Lua versus C code. On the argument of whether having one function loop to update 20 frames or have those 20 frames run the same handler, I have seen no proof to claim which is more efficient. As for what I do myself, that would depend on if the features I intend to implement require 20 frames or if I could just get by on one container frame with 20 sets of Textures and FontStrings. A lot of things depend on what you want the code to do overall and no one solution is viable for everything.

[Phanx]

Originally Posted by Aanson I, myself, have found in the past that I want to intentionally leave as much detail out as possible when asking a question because I fear that things completely unrelated to my question will be flamed.

That's the problem, though. You're basically handing people a random lug nut and asking them why your car makes funny noises when you drive up a hill. Do you do that to your mechanic, too, because you're afraid he might scold you about not getting an oil change in the last 10 years?

Also, my remarks were mainly directed at Barjack and his ridiculous and completely nonsensical rants.

[Barjack]

Originally Posted by Phanx That's the problem, though. You're basically handing people a random lug nut and asking them why your car makes funny noises when you drive up a hill. Do you do that to your mechanic, too, because you're afraid he might scold you about not getting an oil change in the last 10 years? Also, my remarks were mainly directed at Barjack and his ridiculous and completely nonsensical rants.

And my remarks were mainly directed at your willingness to make stupid, sweeping generalizations and criticize code you haven't even seen.

You still haven't answered any of my questions, either. You're willing to attack a person for having the same function being called 20 times a second (a function you haven't even seen) but you're not very willing to actually engage in a defence of your position.

I've given you examples of extremely basic situations with very few frames doing very few things (general buff frames that want to update their timers every 1 second, debuff trackers that want to update frames every 0.1 to 0.25 seconds). Now I want you to tell me why those types of situations are examples of code gone "horribly wrong".

Tell me how I can update two debuff trackers' timer bars every 0.1 seconds without calling the same function 20 times a second. And then tell me why your solution (in which you call the same function a mere 10 times a second) demonstrates its indomitable superiority.

[Phanx]

If you think it's not more efficient to perform a table lookup once, store the result in a variable, and then consult the variable 10 times in the same function, versus performing the same table lookup 10 times in the same function, regardless of how many times you're calling the function, then there's nothing to "defend" or discuss, because we're not even speaking the same language.

Besides, when someone posts a vague psuedo-example, and I say something that amounts to "well, why not do it this way instead?" and you -- rather than providing a more concrete example, benchmarks, or rational arguments of any kind -- respond with a rapid-fire series of hysterical sarcastic gibberish, I really don't have any interest in trying to communicate with you.

[Barjack]

Originally Posted by Phanx If you think it's not more efficient to perform a table lookup once, store the result in a variable, and then consult the variable 10 times in the same function, versus performing the same table lookup 10 times in the same function, regardless of how many times you're calling the function, then there's nothing to "defend" or discuss, because we're not even speaking the same language.

Wow, that's totally what I think! Because I didn't explicitly say the exact opposite in my original comment or anything. Oh wait... or did I?

Originally Posted by Barjack On the other hand, if that lookup has the potential to happen 10 times per function in a function that might happen 20 times per second during combat, then I personally would definitely consider making it local.

Oh. Huh. It turns out I did, actually, say exactly that. Wow. It's almost as if you're willing to attack someone for something they explicitly did not say, in addition to merely attacking people for writing code you haven't seen.