Code profiling

adipose

Is there a way of doing code profiling in Gideros? I badly need the ability to do this.

I have ported my code from an Android project, and have kept nearly the same structure, taking advantage of Gideros class implementation to keep my components the same. At this point the game runs 98% the same as the Java based one, but the performance is abysmal.

Currently I am getting between 5 and 20 fps (it jumps quite a bit), whereas on Java, I was getting 60fps. This is on the Droid 3.

So far I can see that about 40% the time is spent in updating the "physics", and another 40% in placing sprites. Another 20% is unaccounted for, which I assume to be overhead and the actual drawing of the sprite tree.

I can't believe the performance could be this bad in Gideros/Lua, but I don't see anything drastically different from my Java code (perhaps that's part of the problem). I have applied all Lua optimizations that I can think of.

At this point I would like to see if there is a way to isolate what is taking all the time--hence the question about code profiling.

FYI, there are probably anywhere from 30-100 sprites on the screen at a given time, with a few large ones for the background. Does disabling callbacks on these sprites help anything?

phongtt

I can't help but interested in seeing answers for this also. Anyone?

ar2rsawseen

Haven't tried, but maybe ZeroBrane Studio has this functionality
http://www.giderosmobile.com/forum/discussion/1850/quick-demo-of-gideros-debugging-with-zerobrane-studio/p1

techdojo

The simplest method is to use the system.timer to mark time at the beginning and end of a function and then dump it out.

Due to the granularity of the timer this might not be accurate enough, but if you could section out your code and maybe run parts in a fixed loop (say 1000 times) then you could get a better picture of it.

I suspect that a lot of your issues are probably due to the layout of the code and your implementation, make sure your only doing the work you need to do at the point you need to do it. Pre-calculate as much as possible - avoid dynamic memory allocation like the plague, reuse variables / objects etc instead of allocating new ones.

The jumping sounds weird, what is going on when the frame rate drops, use the log file to help show the paths the codes ACTUALLY taking, lastly (as the ninja that is @ar2rsawseen suggested) try using ZeroBrane / Lua debugger to single step through your code - I suspect again something's extras happening that you are unaware of.