Profiling

Gideros comes with an integrated native lua profiler.

For those who don't know what is a code profiler, it is a tool that measure effectiveness of the code and outputs statistics about the CPU usage: number of times each function was called, how much time it took to execute, and where was it called from.

Gideros rpvoides two means of enabling profiling: - By launching a profiling session directly through 'Profile' menu item or toolbar icon from Gideros Studio - By calling Core.profiler* API from lua

In the former case, Gideros Studio will display the profiling results when the stop button is hit in Gideros Studio toolbar. In the latter, you have to handle profiling data collection and display by yourself. Note that even if you started profiling through Gideros Studio, you can still use Core.profilier* API within your code. Gideros profiling API available from lua is: - Core.profilerStart(), which instructs gideros start collecting profiling data - Core.profilerStop(), which pause collecting - Core.profilerReset(), which clears collected data - Core.profilerReport(), which returns a table containing collected profiling data

Enough said about the internals, let's see how profiling can help us!

So suppose you are running the following code:

local function myFunction1(a)
	local function c(a) return math.cos(a*math.pi/180) end
	return c(a)+c(a+1)
end

and happen to use it very often. It is far from being optimized (on purpose, right) and turns out to be slow, but how can we do better ?

Lets ask the profiler how does it run, say we want to run it 100000 times:

for i=1,100000 do myFunction(i) end

This code outputs:

#	Time	Ratio	Count	Function	Location
<a id="f1">[1]</a>	423	0%	1	callFile	=[C] 00421900(callFile)
	423	100%	1	<a href="#f2">Unknown</a>	@main.lua:0:033FAC64
	423	100%	1	<a href="#f1">callFile</a>	=[C] 00421900(callFile)
<a id="f2">[2]</a>	423	4%	1	Unknown	@main.lua:0:033FAC64
	405	96%	100000	<a href="#f3">myFunction</a>	@main.lua:26:033FD87C
	405	100%	100000	<a href="#f2">Unknown</a>	@main.lua:0:033FAC64
<a id="f3">[3]</a>	405	35%	100000	myFunction	@main.lua:26:033FD87C
	265	65%	200000	<a href="#f4">c</a>	@main.lua:27:033FC328
	265	100%	200000	<a href="#f3">myFunction</a>	@main.lua:26:033FD87C
<a id="f4">[4]</a>	265	60%	200000	c	@main.lua:27:033FC328
	107	40%	200000	<a href="#f5">cos</a>	=[C] 6E416FE0(cos)
	107	100%	200000	<a href="#f4">c</a>	@main.lua:27:033FC328
<a id="f5">[5]</a>	107	100%	200000	cos	=[C] 6E416FE0(cos)
<a id="f6">[6]</a>	2	100%	313	gideros_enterFrame	=[C] 00423050(gideros_enterFrame)
<a id="f7">[7]</a>	0	100%	1	broadcastEvent	=[C] 00423340(broadcastEvent)

This is a list of all functions ran by the code sorted by CPU usage (highest first). The first chunk is about a function called 'callFile'. It is an internal Gideros Function which loads each lua file. In our case it was used to launch main.lua, which corresponds to block [2]. But let's focus on our function 'myFunction', we can see it is covered by block [3]:

#	Time	Ratio	Count	Function	Location
	405	100%	100000	<a href="#f2">Unknown</a>	@main.lua:0:033FAC64
<a id="f3">[3]</a>	405	35%	100000	myFunction	@main.lua:26:033FD87C
	265	65%	200000	<a href="#f4">c</a>	@main.lua:27:033FC328

So the function 'myFunction' took, as expected, most of the processing time. Figures tell us that it was called 100000 times and consumed 405ms on CPU. We also learn that it was called from an unnamed function located at main.lua:0, which is the toplevel lua code of main.lua file, and that all the time (100%) spent in myFunction was due to being called by main.lua. More interesting, we discover that 65% of the time (265ms) was spent in calls to function 'c' located at main.lua:27, and that c was called 200000 times, twice per call.

The next chunk is about function 'c': 40% of the time of 'c' was spent in math.cos(), and 60% in the function itself.

We now that calling a function is expensive, and that 'c' function is rather simple. Lets try to inline it:

local function myFunction(a)
	return math.cos(a*math.pi/180)+math.cos((a+1)*math.pi/180)
end

Now profiler report looks like this: (truncated)

< [ 5] 912 100% 1000000 <a href="/profile/main">@main</a>.lua:22 = [ 1] 912 76% 1000000 myFunction <a href="/profile/main">@main</a>.lua:6 > [ 2] 215 24% 2000000 cos =[C] 6E416930

---

< [ 1] 215 100% 2000000 myFunction <a href="/profile/main">@main</a>.lua:6 = [ 2] 215 100% 2000000 cos =[C] 6E416930

myFunction is already faster: 912ms now where we had 3768ms before. We still call math.cos two times. Lets make it (and math.pi) local.

local function myFunction3(a)
	local cos=math.cos
	local pi=math.pi
	return cos(a*pi/180)+cos((a+1)*pi/180)
end

and profiler report:

< [ 6] 798 100% 1000000 <a href="/profile/main">@main</a>.lua:22 = [ 1] 798 73% 1000000 myFunction <a href="/profile/main">@main</a>.lua:10 > [ 2] 216 27% 2000000 cos =[C] 6E416930

We saved time in myFunction, while cos() took the same time.

What if we use new gideros deg to rad operator instead of math.pi and 180 constant ?

local function myFunction4(a)
	local cos=math.cos
	return cos(^<a)+cos(^<(a+1))
end

and profiler report:

< [ 5] 741 100% 1000000 <a href="/profile/main">@main</a>.lua:22 = [ 1] 741 71% 1000000 myFunction <a href="/profile/main">@main</a>.lua:16 > [ 2] 216 29% 2000000 cos =[C] 6E416930

We saved a few more precious milliseconds!

As you can see, the profiler is an useful tool to spot CPU bottlenecks in your app, and some times a few minor changes in the code can make big differences: avoid table access, avoid function calls, avoid duplicate computations.