Originally Posted by watchout
One thing to also note is: Avoid global tables at all costs. WoWs current global table is so overpopulated that you're almost always faster when you first do local x = sometableinglobal; and then do your operations on x. You're even faster if you completely skip the global table and stay within your addon's scope (have a table where everything is inside that you can access using self, or use local-to-file variables if possible).
Also note that accessing anytable.number is always slower than accessing number without a table (100-1000 times or so)
|
I just did a test after logging in, meaning most addons wouldn't have loaded their dynamic or load on demand parts yet, and my global table has 32047 entries. Would be quite interesting to know what the size of the global table actually does to performance. Though most addons are written to use locals, and shouldn't be affected by this, it would slow down the default interface code, which makes *extreemly heavy* use of globals and global function calls like getglobal.
Many things in my UI is my own code though, and I try to pollute the global namespace as little as possible, only adding one global, or in some cases none, and I know many other addon authors will do the same.
You learn a lot of good coding guidelines from this community, this thread is a good example. I just think it is funny that the Blizzard coders aren't learning from this too, their use of globals is frightening, when we know how slow it is compared to locals.
To test how many globals your interface has, use this code:
Code:
/run c = 1; for _ in next, _G do c = c +1 end print(c)