Lua OOP performances...

GregBUG

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

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

moopf

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

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

ar2rsawseen

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

moopf

@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

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

i stay with procedural!! for collision system!

Lobo

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

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

Lobo

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

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

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

@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

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

paulclinger

@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

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