Managing a consistent framerate

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
BlackBulletIV
Inner party member
Posts: 1260
Joined: Wed Dec 29, 2010 8:19 pm
Location: Queensland, Australia
Contact:

Re: Managing a consistent framerate

Post by BlackBulletIV » Wed May 04, 2011 11:55 pm

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.

User avatar
Lafolie
Inner party member
Posts: 804
Joined: Tue Apr 05, 2011 2:59 pm
Location: SR388
Contact:

Re: Managing a consistent framerate

Post by Lafolie » Thu May 05, 2011 12:00 am

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. -!
Do you recognise when the world won't stop for you? Or when the days don't care what you've got to do? When the weight's too tough to lift up, what do you? Don't let them choose for you, that's on you.

pekka
Party member
Posts: 206
Joined: Thu Jan 07, 2010 6:48 am
Location: Oulu, Finland
Contact:

Re: Managing a consistent framerate

Post by pekka » Thu May 05, 2011 6:36 am

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.)

User avatar
BlackBulletIV
Inner party member
Posts: 1260
Joined: Wed Dec 29, 2010 8:19 pm
Location: Queensland, Australia
Contact:

Re: Managing a consistent framerate

Post by BlackBulletIV » Thu May 05, 2011 7:57 am

Thanks for the information, a handy thing to keep in mind.

And yes, os.clock() is definitely seconds.

User avatar
bartbes
Sex machine
Posts: 4944
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: Managing a consistent framerate

Post by bartbes » Thu May 05, 2011 8:23 am

Guys.. os.clock is cpu time..

User avatar
BlackBulletIV
Inner party member
Posts: 1260
Joined: Wed Dec 29, 2010 8:19 pm
Location: Queensland, Australia
Contact:

Re: Managing a consistent framerate

Post by BlackBulletIV » Thu May 05, 2011 9:38 am

In seconds right? It certainly seems to move by seconds.

User avatar
bartbes
Sex machine
Posts: 4944
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: Managing a consistent framerate

Post by bartbes » Thu May 05, 2011 9:41 am

Yeah, but cpu time is not real time.

User avatar
vrld
Party member
Posts: 917
Joined: Sun Apr 04, 2010 9:14 pm
Location: Germany
Contact:

Re: Managing a consistent framerate

Post by vrld » Thu May 05, 2011 9:41 am

os.clock:
Returns an approximation of the amount in seconds of CPU time used by the program.
I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum.

hump | HC | SUIT | moonshine

User avatar
BlackBulletIV
Inner party member
Posts: 1260
Joined: Wed Dec 29, 2010 8:19 pm
Location: Queensland, Australia
Contact:

Re: Managing a consistent framerate

Post by BlackBulletIV » Thu May 05, 2011 9:42 am

Well then, I learnt something new. But the explanation of "seconds" is still partly right, just not in real time.

User avatar
Ertain
Citizen
Posts: 55
Joined: Fri Nov 19, 2010 9:38 pm
Location: Texas, U.S.A.
Contact:

Re: Managing a consistent framerate

Post by Ertain » Sat May 07, 2011 1:40 am

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.
Attachments
love_project1.love
Sample game
(363.61 KiB) Downloaded 57 times
Booted, suited, and ready to get executed.

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests