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?