Using ProfilerService

WARNING: This page uses outdated config language and should not be trusted!

Complete:

Goal of the page

This page introduces a framework-service ProfileService that allows to instrument only some portions of a cmsRun with performance measurument tools. At the moment only callgrind is supported. Extending it to other tools such as IgProf is easy.

Contacts

VincenzoInnocente

Introduction

Callgrind provides an API to start and stop the instrumentation of code for performance measurements. ProfileService exploits the ability of the edm-framework to call specific functions at critical places during the execution of cmsRun to instrument only part of the code and for a given range of events. This allows to skip initialization and finalization phases, to exclude I/O or to instrument just some specific paths. In this way the output covers only the part of interest avoiding post-processing filtering and, at the same time, the processing time is much reduced due to the smaller part of the code than runs instrumented.

Usage

To instrument only a portion of the code add a ProfilerService to the cfg file. For instance adding

  service = ProfilerService {
     untracked int32 firstEvent = 5
     untracked int32 lastEvent = 14
     untracked vstring paths = { "p1", 'p3'}
  }

will instrument paths p1 and p3 starting with event 5 and ending with event 14.

to instrument the full event including I/0 use untracked vstring paths = { "FullEvent"}

run cmsRun under valgrind as valgrind --tool=callgrind --combine-dumps=yes --instr-atstart=no --dump-instr=yes --separate-recs=1 cmsRun myconf.cfg

to analyze the result follow the guidelines contained in the workbook.

instrumenting only a portion of a path

It is also possible to instrument just a portion of a path (for instance just one module). It is enough to enclose the portion to instrument between a StartProfilerAnalyzer and a StopProfilerAnalyzer.

For instance the following fragment of cfg

  service = ProfilerService {
     untracked int32 firstEvent = 2
     untracked int32 lastEvent = 10
  }

  module startProfile1 = StartProfilerAnalyzer {}
  module stopProfile1 = StopProfilerAnalyzer {}
  module startProfile2 = StartProfilerAnalyzer {}
  module stopProfile2 = StopProfilerAnalyzer {}

  path p1 = {
            m1,  (startProfile1 &  (m2, m3)  & stopProfile1)
  }       
  path p2 = {
   (m4, f1) & ( m4,  (startProfile2 & m5 & stopProfile2), m6 )
  }       

will instrument only modules m2,m3,m5. Care should be taken due to the implication of operators , in the path scheduling

Unreliable results may occur if the portion includes a filter: in such a case the StopProfilerAnalyzer may not be executed and the instrumentation will be forced to stop only at the end of the event.

Outer scope instrumentation takes precedence. So, if in the previous example untracked vstring paths = { "p1"} would have been present, the full p1 path would have been instrumented ( while for path p2 the start and stop modules would have continue to be effective though).

Documentation

Parameter Set

type	name	default value	description
untracked int32	firstEvent	0	first event to instrument
untracked int32	lastEvent	std::numeric_limits::max()	last event to instrument
untracked vstring	paths	empty	selected set of paths to instrument

special value in paths:

• ALL: instrument all paths
• FullEvent: instrument all code starting before the Source of firstEvent and ending before the Source of lastEvent+1

Examples

See Usage

Review status

Reviewer/Editor and Date (copy from screen)	Comments
KatiLassilaPerini - 15 Mar 2007	created template page

Responsible: VincenzoInnocente
Last reviewed by: Most recent reviewer