iCMS

Browser compatibility
tested on:
Opera/9.10
Firefox/1.5.0.7
Safari/2.0.4
IE/6.0.2900

Overview

Several profiling tools can be found in IGUANA to ease the duty of finding CPU/memory intensive part of your program.

oprofile

What it is:

oprofile is a lightweight, kernel based profiling facility. It is possible to use oprofile at CERN via a nice, in progress, iguana based GUI.
The GUI is now part of IGUANA > 4.2.2 . If you want to do profiling, but you don't want to install oprofile on your machine you can use lxcmse1.cern.ch. .

MemProfLib

What it is:

MemProfLib is a shared library which can either be preloaded using LD_PRELOAD mechanism or used directly inside IGUANA. In the first place it was though as a memory profiling tool which used glibc malloc hooks to keep track of all the memory allocation. Then it was extended to include speed profiling via JProf like, SIGALARM mechanism.

How to make it work:

MemProfLib can be found in the Ig_Imports/MemProfLib of IGUANA development version (on CVS). Since it is a work in progress(feedback VERY welcome) it is a moving target. One of the most stable/functional versions is tagged with MEMPROFLIB-0_9_0. Once you have compiled it with

# scram b

it can be activated in two different ways. The general purpose way of operating it is obtained by running the program to be profiled with:

# LD_PRELOAD=IGUANA_ROOT/lib/Linux__2.4/libMemProfLib.so program-to-be-profiled

another possibility is to use it within IGUANA with:

# iguana --memproflib

both way of proceeding will start the profiler, and in the end the results are dumped to a file with a gprof like format.

Output file:

The flat profiling informations contains entries as the following:

-----------------------------------------------------------
     492651028 465775672 1/1   _ZN17G4SteppingManager11InvokePSDIPEj  (/afs/cern.ch/sw/geant4/releases/specific/redhat73/gcc-3.2/geant4.5.1.p01/lib/libG4tracking.so) [631]
[0]  465775672 465750904 1     _ZN16G4Transportation12PostStepDoItERK7G4TrackRK6G4Step (/afs/cern.ch/sw/geant4/releases/specific/redhat73/gcc-3.2/geant4.5.1.p01/lib/libG4transportation.so)
          1032      1032 1/1   _ZN11G4AllocatorI15G4CountedObjectI12G4VTouchableEE12MallocSingleEv (/afs/cern.ch/sw/geant4/releases/specific/redhat73/gcc-3.2/geant4.5.1.p01/lib/libG4tracking.so) [1912]
         23736     23736 1/1   _ZN11G4Navigator25LocateGlobalPointAndSetupERK10Hep3VectorPS1_bb (/afs/cern.ch/cms/Releases/COBRA/COBRA_7_2_3/lib/.4::Linux(void)/libG4volumes.so) [1269]
------------------------------------------------------------

since the output is C++ mangled we can unmangle it with

# c++filt > result-file.flat

Which results in:

------------------------------------------------------------
    492651028 465775672 1/1   G4SteppingManager::InvokePSDIP(unsigned) (/afs/cern.ch/sw/geant4/releases/specific/redhat73/gcc-3.2/geant4.5.1.p01/lib/libG4tracking.so) [631]
[0] 465775672 465750904 1     G4Transportation::PostStepDoIt(G4Track const&, G4Step const&) (/afs/cern.ch/sw/geant4/releases/specific/redhat73/gcc-3.2/geant4.5.1.p01/lib/libG4transportation.so)
         1032      1032 1/1   G4Allocator>G4CountedObject>G4VTouchable> >::MallocSingle() (/afs/cern.ch/sw/geant4/releases/specific/redhat73/gcc-3.2/geant4.5.1.p01/lib/libG4tracking.so) [1912]
        23736     23736 1/1   G4Navigator::LocateGlobalPointAndSetup(Hep3Vector const&, Hep3 Vectorconst*, bool, bool) (/afs/cern.ch/cms/Releases/COBRA/COBRA_7_2_3/lib/.4::Linux(void)/libG4volumes.so) [1269]
------------------------------------------------------------

This gives the profiling information for the function G4Transportation::PostStepDoIt(G4Track const&, G4Step const&) (the one indented and with the [0] index on the extreme left), which is called by G4SteppingManager::InvokePSDIP(unsigned) and which calls G4Allocator>G4CountedObject>G4VTouchable> >::MallocSingle() and G4Navigator::LocateGlobalPointAndSetup(Hep3Vector const&, Hep3 Vectorconst*, bool, bool).
In the first column we have the cumulative sum of all the memory allocated by each function in total.
The second column has different meaning if you consider the actual function, its callees or its children.
For the actual function (G4Transportation::PostStepDoIt(G4Track const&, G4Step const&) ) being examined it is the amount of memory allocated within the function itself, and not by the children.
For the children it is the amount of memory allocated when called by the parent function G4Transportation::PostStepDoIt(G4Track const&, G4Step const&).
For the callees (only G4SteppingManager::InvokePSDIP(unsigned) in this example, but could be more) it is the amount of memory allocated when calling G4Transportation::PostStepDoIt(G4Track const&, G4Step const&) from each of them. The indexes between the squared brackets are for easy lookup of functions and correspond to the index between squared brackets which is found in the leftmost position.

Options:

It is possible to specify a variety of options via MEMPROF env variable.

tree: dump the complete call-tree
noflat: do not output gprof style profile information
profilespeed: Profile speed rather than mallocs
byselfsorting: orders the entries in the gprof style profiler with the one which allocated more memory by themselves (without children allocations) first.

Moreover it is possible to filter out some symbols and their children from the profiling. In the ~/.memproflibrc file you can put statement like:

exclude dlopen
exclude malloc

No entries for them appear in the flat file and their contribution is added to their parent.

References

Oprofile main site on sourceforge.......http://oprofile.sf.net
Another non intrusive profiling facility......http://kcachegrind.sf.net
Jprof:mozilla profiling facility......http://lxr.mozilla.org/mozilla/source/tools/jprof/README.html
A little note on how to install on redhat 7.3.1-CERN.......oprofile-note.ps
A little presentation about oprofile and the GUI.......oprofile-presentation.pdf