Lua Performance Tips

[Xgoff]

Is this true for love functions as well? Should you like do

Code: Select all

local print = love.graphics.print

and so on? I already do that with some functions, but only when I want to change them.

i'll usually just use something like

Code: Select all

local lg = love.graphics

not necessarily for optimization, but mainly because 'love.graphics' gets really annoying to type after a while. however, localizing is probably the easiest optimization you can do (one that can possibly increase readability), but it usually doesn't pay off as much unless you have a massive chain of table lookups or something. there's also the problem of having only 200 locals per function (for standard lua, but this might also apply to luajit as well), and sometimes you need some of those locals for other purposes like upvalues

The biggest performance drop in Lua that I've noticed is from creating unnecessary tables (for example in a loop) that get destroyed right away.

i remember reading somewhere that table creation is actually quite expensive, even more expensive than creating closures. collection can be expensive since lua doesn't have a generational gc, so creating lots of temporary garbage (coughvectorscough) can be nasty. 5.2 apparently will have a generational gc but they never got feedback on it which... either means it will be removed or undocumented, probably

[benloran]

This is an extra assignment which is not present in the "localize_method_no" test.

Well, the point of test02 is to test whether it's worth localizing a method within the body of the loop (in the case that you can't localize it outside of that scope). If I move the localization out of the loop, then it's just a repeat of test01. To make it more fair, I guess I could put a throwaway assignment inside the loop in localize_method_no.

- Strangely, custom unpack function is slower than localized unpack.

I'm not that suprised since a custom unpack function would probably have to make more operations to the stack than the regular unpack. "unpack_custom" needs to start a function scope, look up values, push them on the stack, etc.

I guess I figured that unpack itself would need to do those things, too. I have no idea how unpack works under the hood.

- Do not use math.max, math.min. Use conditionals instead.

math.max can work with a variable number of arguments so I assume that's why it's slower in your test.

That's a good point. I think I'll add tests that compare a variable number of arguments as well.

Test 8 probably also does an extra assignment (to a temp variable which is referenced to the "anonymous" function)
A more 'fair' test for funcparam_localized might be:

Code: Select all

         local func1 = function(a,b,func) return func(a+b) end

         local start = getTime()
         for n=1,cycles do
            local func2 = function(a) return a*2 end
            local x = func1(1,2,func2)
         end

I agree, I'll change that.

Thanks for the feedback!

[Robin]

I guess I figured that unpack itself would need to do those things, too. I have no idea how unpack works under the hood.

IIRC, unpack is implemented in C, so that would have the advantage of not needing to be interpreted. Lua's fast, but it's not machine code.

[benloran]

Test 8 probably also does an extra assignment (to a temp variable which is referenced to the "anonymous" function)
A more 'fair' test for funcparam_localized might be:

Code: Select all

         local func1 = function(a,b,func) return func(a+b) end

         local start = getTime()
         for n=1,cycles do
            local func2 = function(a) return a*2 end
            local x = func1(1,2,func2)
         end

I agree, I'll change that.

Actually, I take it back. The original intent of test 8 (I believe... I copied this from the LuaPerformance site) was to show that it's better to localize an anonymous function outside of the loop than to just write an anonymous function inside the function call.

IIRC, unpack is implemented in C, so that would have the advantage of not needing to be interpreted. Lua's fast, but it's not machine code.

That makes sense. I suspected something like that, but the same example on that LuaPerformance site shows the custom unpack as being much faster than Lua's unpack. That's what threw me.

[Robin]

Actually, I take it back. The original intent of test 8 (I believe... I copied this from the LuaPerformance site) was to show that it's better to localize an anonymous function outside of the loop than to just write an anonymous function inside the function call.

Yeah, every time a function statement/expression is executed, a new closure is created.

[Xgoff]

IIRC, unpack is implemented in C, so that would have the advantage of not needing to be interpreted. Lua's fast, but it's not machine code.

That makes sense. I suspected something like that, but the same example on that LuaPerformance site shows the custom unpack as being much faster than Lua's unpack. That's what threw me.

the lua implementation of unpack is faster because... it's not actually the same thing as the builtin unpack

the c unpack has to loop through the provided table to get everything, while the lua implementation just uses a fixed set of direct table accesses; if you only need a certain number of values it will of course be cheaper to do it in lua, but if you need one capable of an arbitrary number of returns then your only choice is unpack. the lua <-> c overhead isn't insignificant either. however, a proper unpack implemented entirely in lua might be faster than the c version if you're using luajit

Actually, I take it back. The original intent of test 8 (I believe... I copied this from the LuaPerformance site) was to show that it's better to localize an anonymous function outside of the loop than to just write an anonymous function inside the function call.

a nice thing 5.2 does is interning closures, if it detects that a function has the exact same definition and upvalues as another, it'll reuse the existing one instead of creating a new one. for example:

Code: Select all

-- in 5.1, 100 closures would be created; in 5.2 only 1 is
local x
for _ = 1, 100 do
    (function () return x end)()
end

it'll still be slower than defining the function outside of the loop/function/whereever, but not by a whole lot. on the other hand it's a lot slower in 5.1

[tsturzl]

Best advice I can give you for code optimization is do it once you're done, do it only in area's its needed, don't over do it, if you don't NEED it don't DO it. Though this advice conflicts heavily with the gamers mindset, where they buy quad-core processors and dual GPUs just to get better FPS in WoW, it doesn't really help you all that much. Seriously, optimization prematurely can kill your project. Optimization once your done, can just add bugs. If you don't NEED it don't DO it.

[miko]

Is this true for love functions as well?

Of course, it is... Just assume that love functions are packed in a global table. Assigning them to local function make them run faster.

unless you have compiled love against luajit - in this case creating more variables makes things slower.

Anyway, I am pretty sure that this is unecessary, cause Löve engine is fast enough. That would be superfluous...

Agree. And if you really want your code faster, use luajit version of love and don't mess with the source code. But then, 90% of the time spent is probably on SDL side, not on Lua side.

[GijsB]

vrld,

when i did some changes to my code so it would get faster it was a diffrency of 0.1 seconds per frame

[slime]

Is this true for love functions as well?

Of course, it is... Just assume that love functions are packed in a global table. Assigning them to local function make them run faster.

unless you have compiled love against luajit - in this case creating more variables makes things slower.

Incorrect. The only time localizing variables will hurt performance in LuaJIT is when localizing a function/variable in a FFI C library namespace directly. This only applies when you are using the LuaJIT FFI! localizing anything else will help performance!

Performance notice: the JIT compiler specializes to the identity of namespace objects and to the strings used to index it. This effectively turns function cdata objects into constants. It's not useful and actually counter-productive to explicitly cache these function objects, e.g. local strlen = ffi.C.strlen. OTOH it is useful to cache the namespace itself, e.g. local C = ffi.C.