Authors CurseForge

Hey all!

I'm wondering about something...

Consider the 2 following examples:

local a, b, c, d, e
local frame = CreateFrame("Frame")

local function foofoo()
    do 
        stuff
    end
end

local function foo()
    a, b = wowBarZ()
    c = wowBarY()
    d, e = wowBarX()
    if (a and c) or (e and c) then
        foofoo()
        print(format("%s%s", b, d))
    end
end

frame:SetScript("OnUpdate", foo)

local frame = CreateFrame("Frame")

local function foo()
    local a, b = wowBarZ()
    local c = wowBarY()
    local d, e = wowBarX()
    if (a and c) or (e and c) then
        local function foofoo()
            do 
                stuff
        end
        print(format("%s%s", b, d))
    end
end

frame:SetScript("OnUpdate", foo)

note: don't mind syntax and all - it's just for the idea

I think you can spot the difference, in the first, all vars are declared and all functions have the file as scope and thus are instantiated. The second, everything that is needed is instantiated on the fly.

Now with the garbage collector in play, I was wondering what was the least intensive way of doing things, aka, what creates the lesser load? Keeping in mind that lua passes by reference...

The first will ofcourse have more initial memory, but having everything at the ready, it only needs to access/read that memory rather then create/write it first.

The second has the benefit of having less constant memory, but higher peak memory. This also needs to be removed again by the garbage collector. Memory jumps a lot more so to say. It is more memory-usage-intensive.

Now the above are only small things with minor impact, however, when doing stuff like tooltips, if on every tooltip-call you have to create roughly 40 locals (random number), when you're mousing through dalaran, you're creating quite a lot of em...

Which would have the lesser impact on a system?

Quote from Broes

Hey all!

I'm wondering about something...

Consider the 2 following examples:

local a, b, c, d, e
local frame = CreateFrame("Frame")

local function foofoo()
    do 
        stuff
    end
end

local function foo()
    a, b = wowBarZ()
    c = wowBarY()
    d, e = wowBarX()
    if (a and c) or (e and c) then
        foofoo()
        print(format("%s%s", b, d))
    end
end

frame:SetScript("OnUpdate", foo)

local frame = CreateFrame("Frame")

local function foo()
    local a, b = wowBarZ()
    local c = wowBarY()
    local d, e = wowBarX()
    if (a and c) or (e and c) then
        local function foofoo()
            do 
                stuff
        end
        print(format("%s%s", b, d))
    end
end

frame:SetScript("OnUpdate", foo)

note: don't mind syntax and all - it's just for the idea

I think you can spot the difference, in the first, all vars are declared and all functions have the file as scope and thus are instantiated. The second, everything that is needed is instantiated on the fly.

Now with the garbage collector in play, I was wondering what was the least intensive way of doing things, aka, what creates the lesser load? Keeping in mind that lua passes by reference...

The first will ofcourse have more initial memory, but having everything at the ready, it only needs to access/read that memory rather then create/write it first.

The second has the benefit of having less constant memory, but higher peak memory. This also needs to be removed again by the garbage collector. Memory jumps a lot more so to say. It is more memory-usage-intensive.

Now the above are only small things with minor impact, however, when doing stuff like tooltips, if on every tooltip-call you have to create roughly 40 locals (random number), when you're mousing through dalaran, you're creating quite a lot of em...

Which would have the lesser impact on a system?

Aside from the syntax error in the second example, it will have significant problems considering you are potentially creating a new function for every FPS.

Quote from egingell

Aside from the syntax error in the second example, it will have significant problems considering you are potentially creating a new function for every FPS.

copy/paste fail... it's early over here ;)

But yeah, as I thought. Keep it clean.

Something else bubbled up though:
I've got a config file, with a global config
config.lua

config = { 
   ["1"] = {
   etcetc

Is there a benefit from renaming that to locals? As everything is passed by reference, that local and global (until either changes) point to the same memory location... what is the benefit of using renaming (local x = config.y) as I so often see in addons? Or is that only "should the global change due to outside influence, at least the local has the original value"?

Quote from Broes

what is the benefit of using renaming (local x = config.y) as I so often see in addons?

Slight speed improvement is usually the reason. The local value is available through an indirection whereas a global requires quite a bit of work.

If you repeat ten times the same "config.foo.bar", "config.foo.baz", ... construct in your code, then the GETTABLE operation is repeated each time. Keeping a local reference like "local foo = config.foo ; foo.bar ; foo.baz" reduces drastically the number of operations done by your code. This is not only faster to execute, but the function prototype will use less memory as well.

Quote from Broes

Or is that only "should the global change due to outside influence, at least the local has the original value"?

In fact, I think most of the time this is either overlooked or ignored, although it can be a perfectly valid reason to use an upvalue.

For your original question, I would say that you probably need to instrument the two solutions and measure the difference, if any. I'm pretty sure the difference is not really noticeable.

Treat functions like tables, only declare them when you absolutely have to, and try to reuse them as much as you can... but also don't be afraid to dereference one so it will GC if you are not going to use it any more.

Quote from Nevcairiel

Creating a new function closure in an OnUpdate will certainly show a visible increase in garbage creation.

I'm not sure he meant to create then call the function in the second example. Only copy the function's code block. In that case, the difference between the two examples is that the first uses a bunch of upvalues but the function context doesn't use any memory space to keep the local variables, whereas the second does the opposite. I haven't checked but I'm pretty sure lua's engine release the space for local at once, whatever the number of declared local variables, so I don't think it matters much how many locals you use.

Declaring a function just to call it later doesn't achieve anything meaningful here.
But yeah, you're right of course, unless it's necessary, never create closure multiple times.


Of course, I can think of at least one example of my own code where I do just that :-) At least I've some explanation in case there's a trial ;-)

Thanks for the responses people, very much appreciated.

Having Java as background, Lua is quite something to get used to in terms of optimization, due to the lack of classes per sé and instantiation etc.

Perhaps it would be an idea if there could be made some sort of thread containing some basic pointers with regards to optimization and code streamlining? More just a general Tips & Tricks when it comes to wow-Lua I suppose

Quote from Nevcairiel

The First Rule of Program Optimization: Don't do it.

Thread finished, right there! :)
Until you know *how* to actually optimize, you really should not.

hence why I ask before I start with it (still analyzing and testing atm) ;)

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"

Donald Knuth

Note the very important word : "premature". What it means is that you shouldn't even think about optimization until you have too (i.e. your code is too slow).

In other word : Write code that is easy to read and follow. Once your program is done, and if it's too taxing, then try to find out where using instrumentation and then try to optimize that part.

as I said, still analyzing and testing atm. So far I have absolutely no reason to worry about optimizing, as it's very lightweight. Me happy :D

Quote from Xinhuan

[...] I mean you should already have decided and picked which algorithms and data structures you are going to use (eg, quick sort versus merge sort, separate hash tables of data or tables of tables of data, etc). [...]

Isn't this standard when writing any code? I mean, just starting to write with no clue on what, why, how and where is pointless. Well, not pointless if you're just in it for the fun of it, but then why bother?