Slicer3:Performance Analysis

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

• GNU gprof
  • gprof is not a good profiler for our needs because it doesn't support profiling multithreaded code.
• oprofile
• Shark 4 (OSX)

Profilers for Multi-threaded Applications

• See the pages on ITK Registration Optimization

Runtime Instrumentation

• Callgrind / KcacheGrind

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_START_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:

• oprofile; run Slicer3 and exit
• oprofile; run Slicer3, load DICOM, exit

KCachegrind:

• KCachegrind; run Slicer3, load DICOM, exit
• KCachegrind; run Slicer3, load DICOM, exit

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