Express a val from a local table as local?
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: Lua Code:
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: Lua Code:
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. |
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.
|
Quote:
Thanks again. I think I just needed reassurance :) Aanson. |
Quote:
Quote:
|
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 ...
Quote:
Quote:
Lua Code:
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. |
Quote:
|
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.
|
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.
|
Quote:
|
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...!
|
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.
|
Do I need to quote your own post for you?
Quote:
Quote:
Quote:
|
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.
|
Quote:
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 |
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.
|
Quote:
Also, my remarks were mainly directed at Barjack and his ridiculous and completely nonsensical rants. |
Quote:
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. |
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. |
Quote:
Quote:
|
All times are GMT -6. The time now is 08:26 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI