Last question, I am at work so I can't test, but I see the Tekkub's tests and I wonder if:
_G["PlayerFrame"]:GetName();
is faster than
PlayerFrame:GetName();
In order to use the second case, in case we don't need loops...
_G["PlayerFrame"] is faster than PlayerFrame only if you defined "local _G = _G" at the top of your file. Because if you didn't, looking up _G itself would be another table lookup because _G._G == _G.
The fastest is really "local PlayerFrame = PlayerFrame" and then using the local table reference from there. This costs 4 bytes of memory to store the reference, and I think 4 more bytes per function that references this upvalue. But programming has alawys been about speed vs memory use.
Ok thanks, so as often, there is not a "must do" but we have choice beetwen little more speed or little less memory usage.
Well, I guess, but I think it's a little misleading to call it a choice between memory and speed in this case, because 4 bytes is negligible. It's probably always worth trading 4 bytes for any measurable speed boost.
I'd say in this case it's more of a tradeoff between speed and code clarity, and even then there's not all that much at stake. :)
It all really depends on how you're doing crap. Blizzy uses getglobal/_G *very* liberally in their code. In an addon, ideally you should be tracking your own frames with locals and almost never need to use _G. Still, given the choice, I'd always take the best performing option, even if I may never notice the difference.
It's probably just a "bad example". I wouldn't be bringing this up if it was about
PlayerFrame:GetScale()
vs
_G['PlayerFrame']:GetScale()
You are right, it's not a great example. The Lua creators specifically call this kind of thing out as "people getting over-excited about _G". The point of _G/getglobal is being able to access variables when composing names, like _G["PREFIX_FOO_"..counter.."_BAR"] and suchlike, rather than execution speedups. If speed really matters in a particular blob of code, then it's time to make smart use of locals, look hard at algorithm choices, write inner loops in hand-coded assembly, etc. :-)
IMHO they should have used 3.0 as an excuse to finally change all the API returns to true/false and remove some of the ambiguity of functions like UnitInParty/UnitInRaid that actually do return a number but if you don't test enough you might assume its just 1/nil.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium_G["PlayerFrame"] is faster than PlayerFrame only if you defined "local _G = _G" at the top of your file. Because if you didn't, looking up _G itself would be another table lookup because _G._G == _G.
The fastest is really "local PlayerFrame = PlayerFrame" and then using the local table reference from there. This costs 4 bytes of memory to store the reference, and I think 4 more bytes per function that references this upvalue. But programming has alawys been about speed vs memory use.
Well, I guess, but I think it's a little misleading to call it a choice between memory and speed in this case, because 4 bytes is negligible. It's probably always worth trading 4 bytes for any measurable speed boost.
I'd say in this case it's more of a tradeoff between speed and code clarity, and even then there's not all that much at stake. :)
instead of
PlayerFrame:GetName()
:p
It's probably just a "bad example". I wouldn't be bringing this up if it was about
PlayerFrame:GetScale()
vs
_G['PlayerFrame']:GetScale()
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou are right, it's not a great example. The Lua creators specifically call this kind of thing out as "people getting over-excited about _G". The point of _G/getglobal is being able to access variables when composing names, like _G["PREFIX_FOO_"..counter.."_BAR"] and suchlike, rather than execution speedups. If speed really matters in a particular blob of code, then it's time to make smart use of locals, look hard at algorithm choices, write inner loops in hand-coded assembly, etc. :-)
Yes, that's exactly why all the API functions return 1/nil instead of true/false. Lua 4 did not have true/false and people used 1/nil instead.