Open main menu

CDOT Wiki β

Changes

Profiling

2,552 bytes added, 13:01, 12 March 2018
no edit summary
{{Chris Tyler Draft}}[[Category:SPO600]]
Profiling is the process of determining how a program is using the resources that it is consuming.
== Resource that can be Profiled ==
 
Profiling produces a clear view of the call graph -- the hierarchy of function/procedure/method calls that takes place during the execution of the program.
Resources consumption that can be analyzed during profiling include:
* Energy (this is a relatively new area of profiling)
== Profiling Granularity and Techniques == Most profiling systems determine resource usage on a per-function basis. Data may be gathered through two different techniques:# Sampling - interrupting the program frequently (such as 10 000 times/second) and determining which function is currently executing (by comparing the [[Register#Program_Counter|program counter]] to the debuginfo of the program).# Instrumentation - adding code to the binary or using debug controls (such as breakpoints) to determine when and how often specific actions take place, such as entry/exit to/from a function/procedure/method. == An example: Profiling with 'gprof' == The <code>gprof</code> tool provides basic profiling capability using a combination of sampling (for times) and instrumentation (for call graph and counts). To use it: # Build the software to be profiled using the <code>-pg</code> (profile generation) option to the gcc compiler. This may require that you modify the makefile or other build instructions, but it can often be done using the CFLAGS or CCOPTS variables -- for example, <code>make CFLAGS="-g -pg -O2"</code># Execute the program. Ensure that you give it a typical to long execution time; if it is an interactive program, run through most of the commonly-used features, and if it is non-interactive, invoke it with common options and give it a good amount of data to process.# Check that a file named <code>gmon.out</code> was produced when the program ran. If not, recheck the previous steps.# Run the <code>gprof</code> program to generate a report: <code>gprof ''filenameOfExecutableBeingProfiled''</code> The output from gprof is a text report. It can be converted to a graphical representation, which is often more useful, using the <code>gprof2dot</code> script to convert it to the GraphViz "dot" format, then using the <code>dot</code> utility to output it in the desired graphics format. Examples:  # produce a PDF gprof ''nameOfExecutable'' | gprof2dot | dot -Tps | ps2pdf - gprof.pdf # produce a PNG file gprof ''nameOfExecutable'' | gprof2dot | dot -Tps | convert - gprof.png # produce an SVG file gprof ''nameOfExecutable'' | gprof2dot | dot -Tsvg > gprof.svg # display on the screen gprof ''nameOfExecutable'' | gprof2dot | dot -Tps | display
Most profiling systems determine resource usage on a per-function basis.
{{Admon/note|Function vs. Methodvs. Procedure|In procedural languages, called code blocks are often called '''functions'''. When programming in an object-oriented language, called code blocks may be called '''methods'''. Older or more general documentation may refer to called code blocks as '''procedures'''. The distinction between functions , methods, and methods procedures is effectively one of terminology and "packaging" only - at the [[Machine Language|machine code]] level, the distinction effectively disappears.}}