That's an interesting one, but is it really worth it? You add everything from _G you use in your addon to the addon namespace, even if you only access it once. An upvalue is still faster than the non-global environment and you loose the ability to access _G directly. Or am I wrong about it?
|
That looks like a giant cluster**** and I would not recommend doing anything like it. If you need functions from one of your addon's files in another, just put them in the namespace table and call them as methods.
Also, that's not really relevant to this thread. If you want to discuss using custom function environments, please take that discussion to its own thread. |
This is used to keep your variables not pollute the _G, and gain some code flexibility.Also, the up-value is not as quick as you think.
Here is a test, a() function contains a long calculation, and after it, there are three call types : 1. Define function in the global, call the global function directly. 2. Define up-values, the use the up-values to "speed up" the calculation. 3. Use the standalone environment, do the calculation. Lua Code:
The result may not be exactly because there are too many things should cost the cpu in the same time, but you can see a lot in it, I run these code three times in lua 5.1.2 on mac shell: Quote:
Quote:
Quote:
In an addon, you don't need access all things in the _G, only what you need is saved to your addon, and if you want access something once, you always can do it like : print(_G.CAT_FORM) Just access if from _G table, you won't save the CAT_FORM in your addon. |
Oh, one more thing, about the memory usage, the up-values cost much more if you use the local vars in many functions in your add-on, Here is a little test :
Lua Code:
So, here is the result: Quote:
|
Quote:
The point of keeping variables in their relevant scope is akin to only allocating memory when you need to use it and proper cleanup when you don't in other languages. All this is done behind the scenes with Lua's garbage collector, but it's still a good practice to follow nonetheless. These so-called "good programming practices" make it easy and simple to program reliable code regardless of which language you're using. The code posted by Rainrider and Phanx are both correct, although the situations of the variables in question by each are completely different. |
Quote:
While it's obvious that, code-wise, a variable should be defined in the smallest scope possible, I think that that is not a tip that belongs in a discussion about optimization :p |
So it is worth to upvalue globals now or not?
|
Quote:
|
Quote:
If you're accessing the global in response to the user checking a box in your options panel, or in response to an event like PLAYER_LOGIN or PLAYER_REGEN_DISABLED that doesn't fire very often, then while you will technically see a speed improvement by upvaluing it, in practical terms there is no value in doing so, so I'd recommend you keep your code tidy and not clutter it up with a bunch of practically useless upvalues. |
Quote:
But, without seeing the actual code in question, it's really pointless to talk about it. |
Well, if you need a var in the OnUpdate or something happened frequently, I suggest you may try the coroutine. Also a test example :
1. First part is using a local var 'sum' to contains the sum result. And then we call it 10000 times. 2. Second part is using a coroutine to keep everything, we also can it 10000 times. Lua Code:
The result is : Quote:
Lua Code:
So, when your frame is visible, the thread will be called again and again, when not, the thread will be stop until the frame is shown again. But, if your handle code is tiny, just use upvalue, in the previous example, if you change the code Lua Code:
Lua Code:
The result should be Quote:
|
Please stop derailing this "basic tips for optimization" thread with your posts about coroutines and custom function environments. If you want to post tutorials on those subjects, please do it a new thread.
|
I find his stuff very interesting to be honest.
1. Don't do premature optimization. 2. Don't sacrifice readability for negligible optimizations. That being said, here's a PDF on performance tips for Lua written by its lead architect. http://www.lua.org/gems/sample.pdf |
Quote:
I also take back the word 'The upvalue is the slowest', I'm confused about the result too, redo the test several times today, only 1 time the upvalue is slower than others, the diff between them is little. I prefer the custom environment just because after some time, the custom environment will store all things that the addon needed, from the point, the custom environment table will be stable compares to the _G. |
Quote:
|
On the subject to declaring variables to their most confining scope next should be noted:
Lua Code:
Code:
-- Compiles into Lua Code:
Code:
-- Compiles into Lua Code:
Code:
-- Compiles into While doing a large amount of variable declarations, next should also be noted (I'll leave the compiled versions out since I don't want to pollute the thread): Lua Code:
If you really want to optimize your addon, you need to look at compiled code and understand how function calls/lua stack works. |
This is still deviating from the point Phanx and I were making. Phanx is stating as a general rule that locals should stay in the tightest scope possible. My posts state that like most rules, there are some exceptions over the argument whether locals should stay in or out of loops.
Among these is the point that when dealing with constants or CPU-intensive calculations that don't change in the loop, you're best left upvaluing them instead of having the loop reinitialize the variable with the same value multiple times. |
Yep, you guys are definitely missing the point. This is a thread about simple, general tips that don't require a lot of coding experience or deep knowledge of how Lua works internally -- it's not meant to cover every possible scenario, and it's not meant to delve into complicated schemes for extreme optimization of every single CPU cycle. I'm tired of asking, but if you want to provide lengthy benchmarking results and tutorials covering every possible exception to the rule, or extreme micro-optimization, please start your own threads for that stuff.
|
Quote:
|
Quote:
p.s. If you are really curious, the test results with your suggestion is : here |
All times are GMT -6. The time now is 06:58 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI