Difference between revisions of "Slicer3:Performance Analysis"

From NAMIC Wiki
Jump to: navigation, search
Line 82: Line 82:
 
  foo();
 
  foo();
 
  CALLGRIND_TOGGLE_COLLECT();
 
  CALLGRIND_TOGGLE_COLLECT();
  CALLGRIND_START_INSTRUMENTATION();
+
  CALLGRIND_STOP_INSTRUMENTATION();
  
 
After you insert the code, recompile, and run callgrind with these flags:
 
After you insert the code, recompile, and run callgrind with these flags:

Revision as of 17:01, 13 March 2007

Home < Slicer3:Performance Analysis
Slicer3

Home

About

FAQ

Status

Downloads

Documentation

Community Support

Developers

Acknowledgements

Links

Slicer 3 Performance Analysis

We are looking into performance analysis on the Slicer3 codebase in order to streamline execution where possible, identify parts of the program to optimize, and determine which parts of Slicer3 are using the most system resources. We are currently in the process of determining which profilers to use on the various Slicer platforms.

Tools

Statistical Profilers

Profilers for Multi-threaded Applications

Runtime Instrumentation

An initial valgrind suppressions file for slicer is in subversion. It includes an example command line to run it with slicer that also uses the VTK, ITK, KWWidgets suppression files.

Sample Usage

Callgrind / KCachegrind

The most basic way to run callgrind is to just run it with your program as an argument, like this:

callgrind ./myProgram

This will produce a file in the directory which you ran callgrind from named callgrind.out.<pid> where <pid> is the process ID of the program that you ran. You can either look at this file itself, or load it into KCachegrind, which is a graphical viewer for profile data. You can run KCachegrind by typing:

kcachegrind

and the graphical user interface will open. You can then either open your callgrind.out file, or if you started KCachegrind from the same directory as your callgrind.out file, it should open it automatically for you.

This will produce a ton of data to sift through. If you are only interested in a particular block of code, you can restrict callgrind to only profile a specific section of code. There are two ways to do this. The first way is to pass the function name you're interested in to callgrind, e.g.:

callgrind --toggle-collect="myFunctionName()"

The second way to do this is to use the CALLGRIND_TOGGLE_COLLECT macros in your code. To do this, you need to include valgrind/callgrind.h, and put CALLGRIND_TOGGLE_COLLECT before and after the block of code you're interested in. Callgrind also has a feature where you can delay starting the instrumentation until just before you start collecting data, which will make things run a lot faster. If you were interested in profiling the function 'foo()', you would need something like this:

#include "valgrind/callgrind.h"
CALLGRIND_START_INSTRUMENTATION();
CALLGRIND_TOGGLE_COLLECT();
// the code I want to profile
foo();
CALLGRIND_TOGGLE_COLLECT();
CALLGRIND_STOP_INSTRUMENTATION();

After you insert the code, recompile, and run callgrind with these flags:

callgrind --collect-atstart=no --instr-atstart=no ./myProgram

Targets

  • DICOM reader / GDCM
  • vtkITK
  • ImageReslice
  • ITK resampler w/ deformable transform

Sample Files

oprofile:

KCachegrind:

Quantify Info

Note: this is not yet working. For me, it crashes trying to load.

An evaluation copy of Rational PurifyPlus is available from www.ibm.com.

To use this on windows, follow the install info then be sure to do the following:

  • Turn off incremental linking in CMake
    • in the CMAKE_EXE_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS
      • change /INCREMENTAL:YES to /INCREMENTAL:NO
      • add /fixed:NO
  • rebuild Slicer3-real.exe
  • create a shell with the slicer3 environment set
    • e.g. source Slicer3-build/bin/Debug/Slicer3SetupPaths.sh
  • in that shell, run
    • Quantify: c:/Program\ Files/Rational/purifyplus/quantifyw.exe
    • Purify: c:/Program Files/Rational/purifyplus/purifyw.exe