Engine Profiling: Difference between revisions
initial post (raw data) |
cleanup |
||
| Line 5: | Line 5: | ||
== Linux == | == Linux == | ||
=== Intro === | |||
There are several ways to profile an application. | |||
'''gprof''' | |||
you control the profiling daemon using opcontrol, as root | |||
The compiler injects special code in the binary that self profiles it when it runs. this is what <code>cmake -DCMAKE_BUILD_TYPE=PROFILING</code> is here for. We are not going to use this. It does not interfere with normal program's work-flow. With spring, it gets so slow that it is unusable for profiling anything in late game (which is where it is needed the most). It requires special compiling options. | |||
'''oprof''' | |||
OProfile uses statistical sampling. It is a kernel module, which every n clock ticks, registers which function is currently being processed. It is lightweight; it may run with almost 0 performance impact. This method always profiles your profiles your whole system; relevant info has to be filtered out after the profiling run has finished. | |||
The downside of statistical profiling, is that it requires at least a certain sample size to achieve good accuracy. Also remember, that ''oprof'' still requires the debug symbols, to resolve addresses into function names. | |||
It can be turned on/off at any time, so for instance, you may skip spring loading so you would only profile in-game runtime. You can also merge multiple profiling sessions. | |||
=== Setting up ''oprof'' === | |||
Required stuff: | |||
* ''oprof'' kernel module | |||
* ''oprof'' package | |||
You will have to load the kernel module. | |||
you control the profiling daemon using ''opcontrol'', as root | |||
as regular user, you can do post-processing using opreport | as regular user, you can do post-processing using opreport | ||
i | i recommend: | ||
call-graph depth of 16 | |||
--callgraph=16 | --callgraph=16 | ||
separate each thread in it's own profile, you can always merge them using opreport afterwards | separate each thread in it's own profile, you can always merge them using ''opreport'' afterwards | ||
also, per application profiles too ofc | also, per application profiles too ofc | ||
--separate=thread,library | --separate=thread,library | ||
Revision as of 10:07, 13 November 2010
Development < Engine Profiling
Engine Profiling
Linux
Intro
There are several ways to profile an application.
gprof
The compiler injects special code in the binary that self profiles it when it runs. this is what cmake -DCMAKE_BUILD_TYPE=PROFILING is here for. We are not going to use this. It does not interfere with normal program's work-flow. With spring, it gets so slow that it is unusable for profiling anything in late game (which is where it is needed the most). It requires special compiling options.
oprof
OProfile uses statistical sampling. It is a kernel module, which every n clock ticks, registers which function is currently being processed. It is lightweight; it may run with almost 0 performance impact. This method always profiles your profiles your whole system; relevant info has to be filtered out after the profiling run has finished. The downside of statistical profiling, is that it requires at least a certain sample size to achieve good accuracy. Also remember, that oprof still requires the debug symbols, to resolve addresses into function names. It can be turned on/off at any time, so for instance, you may skip spring loading so you would only profile in-game runtime. You can also merge multiple profiling sessions.
Setting up oprof
Required stuff:
- oprof kernel module
- oprof package
You will have to load the kernel module. you control the profiling daemon using opcontrol, as root as regular user, you can do post-processing using opreport i recommend: call-graph depth of 16 --callgraph=16 separate each thread in it's own profile, you can always merge them using opreport afterwards also, per application profiles too ofc --separate=thread,library disable kernel profiling, enable userspace profiling
--event=CPU_CLK_UNHALTED:100000:0x0f:0:1 there should be a package with oprof, just install that then insmod oprofile as root
there's special statistical sampling timing functions in modern cpu
my laptop's core 2 duo has them
which somehow sets the lower bar generally for recent stuff :p
opcontrol --event=CPU_CLK_UNHALTED:100000:0x0f:0:1 --callgraph=16 --separate-type=thread,library that has to be sent only once & it will ve saved then, to start the profiler: opcontrol --start to stop: opcontrol --stop in order to make the profile data available to userspace, you'll need to dump the data opcontrol --dump
i use gprof2dot, which takes oprof data, and outputs a nice dot graph
https://code.google.com/p/jrfonseca/wiki/Gprof2Dot
then you can use either graphviz to render to a pic, or there are viewers that don't need so
xdot lets you view it directly https://code.google.com/p/jrfonseca/wiki/XDot
the result is something like this 
you might need help to output the oprof data in a way that gprof2dot can digest, tell me when you reach there
Windows
<Please add>
