Page 4 of 6
Re: Managing a consistent framerate
Posted: Wed May 04, 2011 11:55 pm
by BlackBulletIV
Optimised code is good, to a certain level. You must be very careful how much you optimise, usually the more you optimise, the uglier things look in your code. For example, if optimised code were the only factor we cared about, we'd be coding in machine code, or at least assembly.
Oh I see what you were saying. I think it would be theoretically faster, but the speed gained would be so small that it wouldn't be worth it.
Re: Managing a consistent framerate
Posted: Thu May 05, 2011 12:00 am
by Lafolie
Yeah, that's what I meant by "most cases".
I have learned a lesson about this in the last couple of days anyway. My menu code has become somewhat convoluted. Eh, it works, no point in re-writing it. That reminds me.... I should go and finish that. -!
Re: Managing a consistent framerate
Posted: Thu May 05, 2011 6:36 am
by pekka
I don't know if this optimization has been covered, but it is a useful technique to know to squeeze some performance out of the most time-critical parts of your code.
The upvalue optimization consists of replacing table accesses before function invocation with upvalue accesses. This means that you don't call
love.graphics.draw, but you put the draw fn into an upvalue and call it from there. It has some noticeable timing benefit in this example where I use it on the standard fns
table.insert and
table.remove.
Code: Select all
-- function with direct table access
function table_test(mytable)
for i = 1, 500000 do
table.insert(mytable, i)
end
for i = 1, 500000 do
table.remove(mytable)
end
end
-- same function with accesses of the "table" table replaced by upvalues
do
local insert = table.insert
local remove = table.remove
function table_test_upvalues(mytable)
for i = 1, 500000 do
insert(mytable, i)
end
for i = 1, 500000 do
remove(mytable)
end
end
end -- do block
print "Golly, let's run some timing tests"
t = {}
start = os.clock()
table_test(t)
stop = os.clock()
print ("first test took " .. (stop - start) .. " os.clock() units")
start = os.clock()
table_test_upvalues(t)
stop = os.clock()
print ("second test took " .. (stop - start) .. " os.clock() units")
print "OK, cool, but let's do them again in reverse order"
start = os.clock()
table_test_upvalues(t)
stop = os.clock()
print ("second test now took " .. (stop - start) .. " os.clock() units")
start = os.clock()
table_test(t)
stop = os.clock()
print ("first test now took " .. (stop - start) .. " os.clock() units")
You can also use local variables instead of upvalues. Remember to test how much of an effect it has on execution speed if you do. Optimizing without testing the effects is pretty much useless.
I remember reading somewhere (in PiL?) that using upvalues is faster than using tables, though I don't know if that is generally true. Anyway, on my system with the command-line Lua interpreter I got a benefit of above 10% in execution speed with this change using the above testing program, so in this case it was apparently true. That seems like a major difference, but then again, do you often call the same function 500000 times in a row? In real situations the benefits will be smaller!
Those os.clock() units look a lot like seconds to me, but I was too lazy to check in the docs that they really are
(Also note that if you change the remove call to remove the first item from the tables each time, the tests suddenly take ages to run. It's useful to remember that this is how Lua tables work.)
Re: Managing a consistent framerate
Posted: Thu May 05, 2011 7:57 am
by BlackBulletIV
Thanks for the information, a handy thing to keep in mind.
And yes, os.clock() is definitely seconds.
Re: Managing a consistent framerate
Posted: Thu May 05, 2011 8:23 am
by bartbes
Guys.. os.clock is cpu time..
Re: Managing a consistent framerate
Posted: Thu May 05, 2011 9:38 am
by BlackBulletIV
In seconds right? It certainly seems to move by seconds.
Re: Managing a consistent framerate
Posted: Thu May 05, 2011 9:41 am
by bartbes
Yeah, but cpu time is not real time.
Re: Managing a consistent framerate
Posted: Thu May 05, 2011 9:41 am
by vrld
os.clock:
Returns an approximation of the amount in seconds of CPU time used by the program.
Re: Managing a consistent framerate
Posted: Thu May 05, 2011 9:42 am
by BlackBulletIV
Well then, I learnt something new. But the explanation of "seconds" is still partly right, just not in real time.
Re: Managing a consistent framerate
Posted: Sat May 07, 2011 1:40 am
by Ertain
I am at my wits end. I can't figure out why, at the end of my little demo here, it completely freezes up. I don't know if it's all of the ships I'm drawing, or it's a combination of the drawing and the collision detection.
If you guys wish to sample my game, here it is.