Lua OOP performances...

GregBUG · October 2012

it's only me or when using "oop" in lua the performances are much more slower ?

i mean... i tryed to convert my "raw" collision functions in a better and beauty oop code...

i extended sprite class adding only collision methods (C++ plugin) but the performances are about 2-3 times slower than the "pure" collision functions!

your experience with lua + oop ?

hnim · October 2012

i got same problem. In for loop, i simple get object'member (no caculation), fps is still drop too much.

moopf · October 2012

OOP is generally always slower, regardless of the language. There's an inherent overhead in it, a trade-off between the speed you lose and the modularity you gain.

GregBUG · October 2012

@moof
yes... oop is always slower
but in lua is a little too much slower !

ar2rsawseen · October 2012

agree with @moopf OOP is always slower
agree with @GregBUG 2-3 times is too slower

moopf · October 2012

@GregBUG To be honest I'd really consider procedural instead for your collision functions as speed is the prime factor. Unless there's a real pressing need to do it in OOP, avoid it. Horses for courses, as the saying goes in the UK. 2-3 times slower is a lot though, I agree. In PHP, for instance, it's been quoted over the years at around 15% overhead.

GregBUG · October 2012

what a pity!

my collision system is much "easier" when used in oop!
but it's a time critical code so if i use oop i lose the boost of c++ code !!

...

to "oop" or not to "oop"!! that is the question !

GregBUG · October 2012

i stay with procedural!!

for collision system!

Lobo · October 2012

Is this a pure lua limitation or it depends on the specific way Gideros implements OOP?
I mean, being lua a multiparadigm language there are different ways to understand and implement OOP and Gideros has chosen one. Do you know if there are sensitive differences in performance terms depending on the OOP implementation type in lua?
(i.e, see different techniques in http://lua-users.org/wiki/ObjectOrientedProgramming)

Nascode · October 2012

@GregBUG @hnim could you give some example code in pure lua for this case?
@Lobo lets ask @atilim for your question

Lobo · October 2012

yes, it would be great if @atilim could give us just a small clue about differences in performance in lua using different oop approaches, and why they've chosen this particular one.
Personally I've found Gideros' oop structure very elegant and clear, and in general all the framework gives you the feeling of something well designed and sensitive towards the developpers, it's easy to structure your code, it's easy to decide how to organize mentally your work and keep a global logic for your app, which for me it's very important in order to advance. At least for me oop it's basic for that and It would be a pity if for some uses performance differences would be sooooo important...

GregBUG · October 2012

in my situation i have only extended Sprite class adding 9 extra methods (written in c native code with Gideros Plugin system)

ex:

mySprite:boxToBox(spriteB.x, spriteB.y, spriteB.w, spriteB.h)

the same thing using procedural is:

boxToBox(spriteA.x, spriteA.y, spriteA.w, spriteA.h, spriteB.x, spriteB.y, spriteB.w, spriteB.h)

called in a simple "for" loop
(check "maxBox" Sprites for collision with every sprite on screen...)

<pre>
-- procedural version
local function onEnterFrame(event)
	s = os.timer()*1000
	--local n=0
	for outer = 1, maxBox-1 do
		for inner = outer+1, maxBox do
	--		n=n+1
			if tntCollision.boxToBox(players[inner].xPos, players[inner].yPos, 46*players[inner].xScale, 40*players[inner].yScale,
						   players[outer].xPos, players[outer].yPos, 46*players[outer].xScale, 40*players[outer].yScale) then
						players[inner].inCollision = true
						players[outer].inCollision = true
			end
		end
	end
	--print(n.." collision checks per frame ")
	--e = os.timer()*1000
	--print(e-s)
end

same loop but using OOP tnt Collision version

<pre>
local function onEnterFrame(event)
	s = os.timer()*1000
local n=0
	for outer = 1, maxBox-1 do
		for inner = outer+1, maxBox do
			n=n+1
			if players[inner]:boxToBoxCollision(players[outer]) then
						players[inner].inCollision = true
						players[outer].inCollision = true
			end
		end
	end
	print(n.." collision checks per frame ")
	e = os.timer()*1000
	print(e-s)
end

on my PC for 1000 sprites (so 499500 check for frames!!! this is a stress test!:) )

procedural code took about 300ms
oop code about 950ms

in this case oop is too slow!

(ps: BTW i'm a noob on lua OOP)

what do you think ?

@atilim ? there is space to optimize Lua OOP ?

john26 · October 2012

It seems that in the OO case, Lua needs to do some processing before the C-code is actually run. So for writing plugins, the procedural approach seems to be best.

In TNT, the best thing might be to provide a function that does multiple collision detections rather than the Lua programmer going through a loop. Its best not to have lengthy nested loops in Lua, that's when the interpeted nature of Lua really causes trouble!

If you were to provide such a function, I'm guessing the OO/imperative thing wouldn't matter so much...?

paulclinger · October 2012

@gregbug, it seems like in the OOP case additional time is spent on extracting values from attributes, which is already done in your procedural example.

I'm curious how much better (or worse) the performance is going to be if you reduce the table lookups to using a local variable (even in the procedural case):

Try

                        local pinner, pouter = players[inner],players[outer]
			if pinner:boxToBoxCollision(pouter]) then
						pinner.inCollision = true
						pouter.inCollision = true

instead of

			if players[inner]:boxToBoxCollision(players[outer]) then
						players[inner].inCollision = true
						players[outer].inCollision = true

and

                        local pinner, pouter = players[inner],players[outer]
			if tntCollision.boxToBox(pinner.xPos, pinner.yPos, 46*pinner.xScale, 40*pinner.yScale,
						   pouter.xPos, pouter.yPos, 46*pouter.xScale, 40*pouter.yScale) then
						pinner.inCollision = true
						pouter.inCollision = true

instead of

			if tntCollision.boxToBox(players[inner].xPos, players[inner].yPos, 46*players[inner].xScale, 40*players[inner].yScale,
						   players[outer].xPos, players[outer].yPos, 46*players[outer].xScale, 40*players[outer].yScale) then
						players[inner].inCollision = true
						players[outer].inCollision = true

GregBUG · October 2012

@paulclinger
not noticeable differences.... (tested only on desktop player BTW)
but creating a local variable inside a loop slows down the performance right?

paulclinger · October 2012

@gregbug,
> creating a local variable inside a loop slows down the performance right?
It does, but the payoff for not doing a table lookup (especially multiple times) should be larger. It may even be better to allocate the variable outside of the loop and just assign the value to it.

btw, you have some code (like "n=n+1") commented out in the procedural, but uncommented in the OOP version. Is it just in the post or in the actual test too?

GregBUG · October 2012

@gregbug,
> btw, you have some code (like "n=n+1") commented out in the procedural, but uncommented in the OOP version. Is it just in the post or in the actual test too?

oh yes... it's only on the post....

the test code executed is the same

ps: in the procedural version your modification speedup a little bit (310ms vs 380-390ms per frame)

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Lua OOP performances...

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Lua OOP performances...

Comments