Sometimes it's nice to be wrong (Lua performance)

Durante · Post by **Durante** » Mon Oct 24, 2005 1:32 am

I was pretty disappointed just now that -- after finally implementing one of the more complex things about my game correctly -- Lua seemed to be far slower than I expected, even though I included many early exits, etc.

Well, I tried various possibilities of speeding things up, but none helped much. I already contemplated the horrifying possibility of implementing my game in C when I finally saw the impact of line [1].

Code: Select all

	Circle&#58;eachLine&#40;function&#40;p1, p2&#41;
		-- do nothing for current line
		if not &#40;p1 == self.cur_point or p2 == self.cur_point&#41; then 
			screen&#58;print&#40;20, 30, "oki", white&#41; -- &#91;1&#93;
			-- check for hit on horizontal line
			if hor and not&#40;self.dir&#91;2&#93;==0&#41; and self.y == p1&#91;2&#93; and
					is_bound&#40;self.x, p1&#91;1&#93;, p2&#91;1&#93;&#41; then -- we hit it
				self.dir = &#123;math.sgn&#40;p2&#91;1&#93;-p1&#91;1&#93;&#41;*2, 0&#125; -- follow
				if not self.cur_point then -- are we free roaming?
					self.cur_point = Fibers&#58;resolve&#40;self.x, self.y, p2&#41;
				else self.cur_point = p1 end
				return
			-- check for hit on vertical line
			elseif not&#40;self.dir&#91;1&#93;==0&#41; and self.x == p1&#91;1&#93; and
					is_bound&#40;self.y, p1&#91;2&#93;, p2&#91;2&#93;&#41; then -- we hit it
				self.dir = &#123;0, math.sgn&#40;p2&#91;2&#93;-p1&#91;2&#93;&#41;*2&#125; -- follow
				if not self.cur_point then -- are we free roaming?
					self.cur_point = Fibers&#58;resolve&#40;self.x, self.y, p2&#41;
				else self.cur_point = p1 end
				return
			end
		end
		hor = not hor 
	end&#41;

Hmpf. While prematurely optimizing everything, I overlooked a debug print to the screen that was executing every single iteration. I commented it out, and now my I'm back at a very easy 60 FPS.

What to learn from that? Lua is no way that slow, and make sure that you're doing only what you think you're doing.

While I'm giving advice:
If you use the fast method of developing and are not restarting LuaPlayer between tests do not use require. Use dofile. This was already pointed out by Sprak here but is important enough to mention again (and again, and again). I knew about it and even posted in that thread but still fell into the trap. It can cause very subtle bugs where some files are a new version while others still do the old thing.