Using PerfReport

Complete: 3

THIS DOCUMENTATION DOES NOT APPLY TO CURRENT CMSSW RELEASES

is here for mere historical reasons.

Goal of the page

This page is intended to explain how to use PerfReport to generate static HTML reports from performance profiles.

Contacts

If you experience any kind of problems with PerfReport, please contact me immediately. Write to: robin.alexander.moser@cernNOSPAMPLEASE.ch

Introduction

PerfReport generates static HTML reports from performance profiles in various formats.

The most recent released stable version of PerfReport is 2.0.0.
It creates HTML reports from profile data output by Callgrind FCE (Full Callstacks Extension) and imports IgProf profiles natively. It can also produce reports in the same look and feel from the output generated by the edmEventSize tool. PerfReport 2.0.0 is available as an RPM in the CMS repository. Check instructions on how to configure and run below.

PerfReport 1.0.0 is now deprecated and available only in the form of a source tarball. You can use PerfReport 1.0.0 if you need to create HTML reports from standard Callgrind files. For all other purposes, please use PerfReport 2.0.0. If you want to profile with Callgrind, please consider using the patched version (FCE). Or else, consider using IgProf instead.

Callgrind FCE is currently being finalized and is foreseen to be published in the form of an RPM in the near future. For the time being, Callgrind FCE has to be built from its sources (see download section).

Please find separate manuals for 2.0.0 below and 1.0.0 here.


PerfReport 2

Getting started quickly

Your first steps with PerfReport 2 can be done as follows:

Installing and configuring

Initialize PerfReport in your environment by doing (depending on shell)

source $VO_CMS_SW_DIR/slc4_ia32_gcc345/external/perfreport/2.0.0/profile.d/init.sh
or
source $VO_CMS_SW_DIR/slc4_ia32_gcc345/external/perfreport/2.0.0/profile.d/init.csh
where $VO_CMS_SW_DIR points to your CMSSW installation directory. If the PerfReport path does not exist, then ask the person in charge to install the PerfReport package (as found in official cms repository), or, to do it yourself, follow the instructions about installing packages at https://twiki.cern.ch/twiki/bin/view/CMS/CMSSW_bootstrap.

On LXPlus (64bit SLC4), a working command to get perfreport in your path is

source /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/perfreport/2.0.0/etc/profile.d/init.sh
(or init.csh if you use tcsh instead of bash shell)


A simple report from IgProf data

IgProf normally outputs a gzipped ASCII profile. Make sure you

gunzip
it first. After that, type
perfreport -fi -i (your igprof file) -o (output directory)
PerfReport will then create your HTML report in the output directory you specified. The entry page is called overall.html.



A simple report from Callgrind FCE

Callgrind FCE is currently being finalized and will be released as an updated Valgrind package in the near future. As long as this is not done, you can use the current test version of Callgrind FCE located in my public AFS directory. Since Callgrind FCE is loaded as a Valgrind module, it can run with your local Valgrind installation which does not need to be patched. Simply type

setenv VALGRIND_LIB /afs/cern.ch/user/m/moserro/public/vgfcelib
or
export VALGRIND_LIB=/afs/cern.ch/user/m/moserro/public/vgfcelib
and then run Callgrind as
valgrind --tool=callgrind --fce=(outputfile).fce cmsRun (...your configuration...)
or
valgrind --tool=callgrind --fce=(outputfile).fce --instr-atstart=no cmsRun (...your configuration...)
if you want to use ProfilerService/ProfilerAnalyzer. After that, type
perfreport -ff -i (your fce output file) -o (output directory)
PerfReport will then create your HTML report in the output directory you specified. The entry page is called overall.html.



A simple report from edmEventSize

After obtaining an ASCII profile from edmEventSize, type

perfreport -fe -i (your edmeventsize file) -o (output directory)
PerfReport will then create your HTML report in the output directory you specified. The entry page is called objects_pp.html.



A simple regression report for either IgProf or Callgrind FCE

To create a regression difference analysis between an older and a newer profile, type

perfreport -fi -i (newer profile) -r (older profile) -o (output directory)
for IgProf files or
perfreport -ff -i (newer profile) -r (older profile) -o (output directory)
for FCE files. PerfReport will then create your HTML report in the output directory you specified. The entry page is called overall.html.



More sophisticated analyses

PerfReport offers a big variety of configuration options and filters you can use to select from the profile the data you are interested in, remove unwanted parts, aggregate costs in various ways, collapse set of functions, inline costs into callers, specify renamings in the case of regression analysis, etc. To make use of these features, please take the time to read the complete manual below.



The command line

To invoke PerfReport, please type

  perfreport -f(f|i|e) -i (profile)

The switches -f and -i are mandatory. If omitted, the program halts:

      -f(f|i|e)

      -i (inputfile)
      is used to specify the input file. If regression analysis is requested, this is the more recent profile.

In addition, there is a number of optional switches:

      -c (regconfig)
      specify the filename of the regression config XML. If omitted, the standard config is used. If -r is omitted, -c is ignored.

      -d (reportdesc)
      specify the filename of the report description XML. If omitted, the standard description is used.

      -o (outdir)
      specify the output directory for HTML/PNG production. If omitted, the current directory is used.

      -r (profile)
      specify the filename of the second profile. This is the older preofile for regression analysis. If omitted, no regression analysis is performed.

      -t (tempdir)
      specify a temporary directory for intermediate analysis data. If omitted, '/tmp/' is used.

      -m 'key,value'
      add the given metadata pair. This information will be displayed on all main pages. Repeat the switch to add multiple pairs.

      -y (counter)

      -p
      disable graphics production with Python/MatplotLib and store Python scripts (.py) in the output directory instead for later conversion to graphics.



Authoring PerfReport 2 XML report descriptions

1. Obtaining copies of the standard descriptions

The initialization scripts for PerfReport automatically set an environment variable called PERFREPORT_PATH which will point to the directory where the standard XML report descriptions that PerfReport uses are located. If you type

ls $PERFREPORT_PATH/*.xml
you will obtain a list of the (currently 4) standard report descriptions that PerfReport uses by default if you omit the -d switch. Here is what these XML files are used for:


  • $PERFREPORT_PATH/pr2allstd.xml. This is the standard report description used to produce reports for IgProf and Callgrind FCE.


  • $PERFREPORT_PATH/pr2edmeventsize.xml. This is the standard report description used to produce reports for edmEventSize.


  • $PERFREPORT_PATH/pr2cmsswfltmsg.xml. This is an alternative description suitable for producing IgProf and Callgrind FCE reports. It has an additional filter activated which prunes all the branches below any function called edm::Message*. You might want to use this description to filter out unwanted contributions arising from message logging as present in the nightly builds of CMSSW. To use this report description, simply type
    perfreport ... -d $PERFREPORT_PATH/pr2cmsswfltmsg.xml ...
    and combine with any other options you like.


  • $PERFREPORT_PATH/pr2stdregconf.xml. This is the standard regression configuration file which PerfReport uses whenever you omit the config switch -c. See the section below about regression config files.

If you want to write your own filter descriptions to make a different kind of analysis, the easiest way is to copy the corresponding standard XML file (in most cases pr2allstd.xml) to some directory of yours and to modify it there accordingly, following the instructions about XML descriptions you can find below. Then, invoke PerfReport adding the -d switch and the file name of your modified XML.

You can even edit the XML files in the $PERFREPORT_PATH to change the standard behaviour of PerfReport without having to specify the -d switch. However, you are discouraged to do that as you might get confused by your own changes at a later point in time and cleaning them up will require reinstalling PerfReport.



2. Top level schema and the <Report> element

An XML report description has the following layout.

<Report>

 ...(options) ...

 <ReportSection>
  ...
 </ReportSection>

 <ReportSection>
  ...
 </ReportSection>

 ...
</Report>

Every report section defines a specific view of the data represented in the report and has its own entry page together with, possibly, subpages linked from there.

To specify global report options, you can use the following tags:

subelement purpose
GlobalFilters Use this tag to specify a chain of filters which will be applied to the profiling data before it is analyzed, aggregated and reported. The syntax of the tag is as follows:
<GlobalFilters>
<Filter>
...
</Filter>
<Filter>
...
</Filter>
...
</GlobalFilters>
The filters are applied one after another in the order you specify. See the section on filters below to understand how to describe the properties of each filter.
CallstackAnalysis Put yes inside this element to have PerfReport create an extra page outside of any report section, showing global callstack statistics (top-cost callstacks, callstack depth histogram, ...). Defaults to no if missing.

3. The <ReportSection> element

The <ReportSection> element represents a main page within the report, consisting of a table of (possibly aggregated) report items and, optionally, graphical representations of that data. Subpages which give detailed information about the items listed may be attached to such a page.

All child elements of a <ReportSection> are optional and can be omitted. The simplest meaningful XML report description therefore is

<Report>
 <ReportSection>
 </ReportSection>
</Report>

It will produce a standard report with default options which shows the top 20 functions overall in a table and a pie chart.

Optionally however, you can add any of the following subtags:

subelement purpose
MainTitle Specifies the main heading for the entry page of the reportsection. Try to meaningfully describe here what the page shows.
SubTitle Specifies the subtitle for the entry page of the reportsection. Use to further describe what is the content of the page.
DisplayItems Put an integer in this subtag which determines how many entries should be at most printed in the list on this page and on its subpages. If any of the lists exceeds this number, the remainder of the report items is summarized in an {others} entry. If the reportsection lacks this tag, the default value is used, which is 20. Set the value to zero if you wish to have no limit at all. Be aware that if your input data devises a symbol table with a lot of entries (as it is obviously the case with CMSSW), then producing lists of unlimited length will make the report both huge and unbrowsable.
OutFile Specifies the filename for the entry page of the reportsection. Provide only the filename and NO path; the utility will concatenate the name with the output path specified at invocation time.
ProducePieCharts Put the value yes in this tag to activate production of pie charts on this page and its subpages. Put no to deactivate it. Any other value or a missing tag is interpreted as no.
ProduceLegends Put the value yes in this tag to activate production of legends for the pie charts on this page and its subpages. Put no to deactivate it. Any other value or a missing tag is interpreted as no. If you have deactivated production of charts on this page, this value is ignored.
ProduceInfoPages Put the value yes in this tag to activate production of function info pages (showing callers and callees) for every function appearing on this page and its subpages. Put no to deactivate it. Any other value or a missing tag is interpreted as no.
Aggregation Use this tag to specify in what way data should be aggregated in this report section. The description uses templates or custom aggregates and is described here. If you omit the tag, single cost elements (functions) are shown in the top-level list without appying aggregation.


Whenever the utility builds a table within this report section, it will display a set of columns, according to which of the following options you activate:

subelement purpose
ShowCallCount Shows the number of times a given function has been called. This column is visible by default, given that the report type is either Callgrind FCE or IgProf memory. Put no to override. In case of IgProf performance or EdmEventSize, this option is ignored.
ShowInclusives Shows inclusive cost numbers. This column is visible by default.
ShowSelfRelatives Shows percentages of self cost relative to the total cost in the list. This column is visible by default.


You may also configure the way in which function names are displayed. To this end, add a <NamingDiscipline> element to the <ReportSection> and put one of the following values inside:

value meaning
FunctionName Displays only the name of the function without namespace or type information.
FunctionNameWithSignature Displays the function name inclusive of return type and argument list.
FullFunctionName Displays a fully qualified function name including all levels of preceding namespaces. This is the default.
FullFunctionNameWithSignature Displays a fully qualified function name including all levels of preceding namespaces plus return type and argument list.
IntelligentName Tries to guess what is the most 'useful' information. This is: displays the top-level namespace, then, if necessary, dots (...), then the lowest-level namespace (which is most likely the class name), then the function names. Removes all templating information and signature (templates are replaced by dots if the template collapser is deactivated). However, if the given function is the definition of a C++ operator then signature and return type information is displayed.

Help with improving on these rules and send us your suggestions!

If you want to control the ordering used to sort the items in the list, add a <SortBy> element to the <ReportSection> and put one of the following values inside:

value meaning
SelfCost Sorts by descending self cost. This is the default.

Note: in case of edmEventSize profiles, this refers to the plain object size.

InclusiveCost Sorts by descending inclusive cost.

Note: in case of edmEventSize profiles, this refers to the compressed object size.

FullFunctionName Sorts by the full function name (inclusive of namespace/class information), alphabetically.
FunctionName Sorts by the function name (without namespace), alphabetically.

Please be aware that the sorting takes place before truncation of the list. So if you set the displayitems property to 20 and the sorting discipline to functionname, you will end up with a list containing the first 20 functions w.r.t. alphabetical ordering.

If you are creating a report with many subsections or with subsections that are logically related, it usually makes sense to add links to the pages that connect them to one another. To this end, the tool will produce a header on every page where all those links are collected and hierarchically grouped. For this feature to work you will have to provide information on where to position the current reportsection in the hierarchy. Use the following tags to do this:

subelement purpose
IncludeNavHeader Put yes inside this element to place the header on the page that displays the current reportsection. It will be possible to navigate among all reportsections that include the header. Those which don't are not reachable via links and constitute separate entry points into the report. The default is no. You can omit the tag.
NavLevel1Caption Provide a short name for the highest-level category the current reportsection belongs to. To be displayed in the leading row of the header.
NavLevel2Caption Provide a short name for the mid-level category the current reportsection belongs to. To be displayed in the middle row of the header.
NavLevel3Caption Provide a short name for the the current reportsection. To be displayed in the lowest row of the header.

4. Describing a data filter using a <Filter> element

Filters in PR2 allow for more generic operations on the profile data than just separating wanted from unwanted elements (as in PR1). There exist two types of filters, the ones which need an <ItemSet> parameter and the ones which don't. In the first case, the syntax is

<Filter>
  <Type>...</Type>
  <ItemSet>
    ...
  </ItemSet>

</Filter>

and in the other case simply

<Filter>
  <Type>...</Type>
</Filter>

Within the <Type> tag, specify the kind of filter you want to apply. The following exist:

Type filter action and purpose
CollapseItemSet Collapses a given set of functions to be reported as only one function. The set has to be specified using the <ItemSet>-tag of the filter element (see dedicated section below).

illu_collapse.png

CollapseTemplates Collapses all functions that were generated by the compiler from the same template, e.g. multiply<int> and multiply<float> are collapsed and treated as the one function. The Collapser does not distinguish between the different places in which a template can occur, such that vector<int>::push_back and vector<double>::push_back are equally collapsed. If different instances of templated function reside in different libraries, they are nevertheless collapsed. The 'library' of the collapsed element will be reported in terms of a list mentioning all the where instances of the template occur.

This filter does not have an ItemSet property to it.

CollapseTemplatesSeparateLibs Same as CollapseTemplates, but elements are not collapsed across libraries. That is, if instances of the same function template are linked into different libraries, they are kept apart in the performance report. The flat list will show identical names for such functions (since the templates have been stripped). By navigating to the function profile, you can check that the elements reside in distinct libraries.

This filter does not have an ItemSet property to it.

Prune Removes a given set of functions (specified by the ItemSet subelement) from the report by pruning the respective branches in the profile tree. The costs of the given elements as well as all costs in any descendants will disappear from the report.

illu_prune.png

Typical use cases for this type of filter:

  • remove contributions of elements that do not actually belong to the algorithm under test, like startup and administrative functions, message logging or debug output.
  • remove funcion calls that have been accidentally done
SubtreeInline Removes a given set of functions (specified by the ItemSet subelement) from the report by inlining the inclusive weight of the respective branches into their callers. That is the total call cost to any of these elements will be added to the self cost of their respective callers and the element as well as all of its descendants will disappear from the report.

illu_subtreeinline.png

Typical use cases for this type of filter:

  • inline into the callers the costs of already optimized, unmodifiable or external auxiliary code which does not normally callback into the system or for which you know one or multiple particular entry points. If your profiling target for instance uses an external library for string manipulation or expression evaluation which is called from many different places, you may want to see which of YOUR functions incur the respective cost by calling these functions instead of making the trivial discovery that string management is a major contributor to the performance costs. In this case, remove the given library using SubtreeInline mode. If the library in turn calls other auxiliaries, say memory management, the costs of those calls will go into the caller while YOUR functions using memory management as well will not be affected such that you can see for what amount of memory allocation overhead your own code is responsible.
NodeInline Removes a given set of functions (specified by the ItemSet subelement) from the report by inlining the self weight of the respective nodes into their callers. Only the self cost of each node matching the item set will be inlined into the caller. The descendants called by the function removed will be inherited by the caller.

illu_nodeinline.png

Typical use cases for this type of filter:

  • inline into the callers the costs of already optimized, unmodifiable or external auxiliary code which calls back into your code or for which you do not know any entry point. If for instance you want to eliminate all separate mentionings of std::... functions from the report and instead inline these costs into the callers, use the NodeInline mode. If your program uses functions like std::qsort which calls back to an operator<(...) for comparison, then only the cost of qsort will be attributed to the caller while the cost of the comparison and all of its descendants are retained separately.
Skip Removes a given set of functions (specified by the ItemSet subelement) from the report by making their callers inherit their descendants but deleting the self costs arising in them.

illu_skip.png

There is no typical use case for this filter. Skip was the only removal mode in PerfReport 1 which had to deal with incomplete information coming from standard Callgrind and can be used to emulate this behaviour in order to be able to compare new results with old reports.

5. Describing a set of functions (/report items) using an <ItemSet> element

The <ItemSet> tag is built in the follwing manner:

<ItemSet>
 <Type> ... </Type>
 ...
</ItemSet>

Depending on the type of set you select inside the <Type> subtag, there are different options you can select below.

The following item set catgeories are available:

Type purpose and available options
ExactMatch The set contains every report item (function) for which a given property matches a given string value. Specify the propery you want to use inside a <Property>-tag following the type. Specify the value you want to match it to inside a <Value>-tag following the property. Be careful to use &gr; and &lt; inside value tags if you want to use > or < signs inside your string constants. The list of properties available for the property tag can be found below.
RegExpMatch This set contains every report item (function) for which a given property matches a given pattern which is interpreted as an EXTENDED POSIX regular expression. Specify the propery you want to use inside a <Property>-tag following the type. Specify the pattern you want to match it against inside a <Pattern>-tag following the property. Be careful to use &gr; and &lt; inside pattern tags if you want to use > or < signs inside your regular expression. The list of properties available for the property tag can be found below.
And The boolean connective And ItemSet contains every report item (function) that is contained in two given operand ItemSets. For example, use
<ItemSet>
<Type>And</type>
<LeftOperand>
<ItemSet>
...
</ItemSet>
</LeftOperand>
<RightOperand>
<ItemSet>
...
</ItemSet>
</RightOperand>
</ItemSet>
Inside the <LeftOperand> and <RightOperand>-blocks you can use standard <ItemSet>-blocks to describe the operand sets recursively.
Or The Or-ItemSet contains a report item iff one of the two specified operand ItemSets contains it. The syntax is analogous to the And-case.
Not Write
<ItemSet>
<Type>Not</Type>
<Operand>
<ItemSet>
...
</ItemSet>
</Operand>
</ItemSet>
to build a filter through which a report item passes if it does not pass the given operand filter.

For the first two ItemSet types, the following proterties can be chosen inside a <Property>-tag:

Property meaning
Library The library where the function is stored. An appropriate value could for example be "mylibrary.so".
FirstNamespace The name of the namespace the function belongs to. Only the first level of nesting is used, so if the function is called A::B::C::f(), then the value of FirstNamespace is A.
FullNamepsace The full name of the namespace the function belongs to. All levels of nesting are used, so if the function is called A::B::C::f(), then the value of FullNamespace is A::B::C.
LastNamepsace The name of the innermost namespace the function belongs to. Only the last level of nesting is used, so if the function is called A::B::C::f(), then the value of LastNamespace is C. This usually corresponds to the name of the class.
FunctionName The name of the function. Namespace and class information, return types, function signature, etc. are all removed. For instance, if the function is called void A::B::C::f(int x), then the value of FunctionName is f.
FullFunctionName The full name of the function, inclusive of namespace(s) and class. Return types, function signature, etc. are removed. For instance, if the function is called void A::B::C::f(int x), then the value of FullFunctionName is A::B::C::f.

Authoring PerfReport 2 XML regression configuration files

PerfReport 2 XML regression configuration files have two ingredients: the two quantitative parameters used for regression and the renamings that should be applied to function names when matching symbols of the two profiles. The global structure of a regression config file is a follows:

<RegressionConfig>
 <ThresholdDecrease>...</ThresholdDecrease>
 <ThresholdIncrease>...</ThresholdIncrease>
 <Renamings>
    ...
 </Renamings>
</RegressionConfig>

Setting quantitative regression parameters

When PerfReport creates a regression report, comparing an older with a newer profile, it can report for every report item

  • the absolute amount of change in cost in every cost column (inclusive of relative columns which will yield the amount of change in relation to the other items)
  • the relative amount of change in cost in every cost column
  • the movement the item has done within the complete ranking of cost-intensive functions
However, if PerfReport displayed all the information for every symbol in the two profiles, the regression report would become overfull and hardly informative. Therefore, PerfReport displays such regression and change information for items which have gone through a significant change in cost exclusively. The definition of the term of significant is what you can influence using the two parameters described here, ThresholdIncrease and ThresholdDecrease. Let's say that you use the numbers 0.4 and 0.6 for the two parameters. Then this means that an item which undergoes a change in self cost of at least +0.4 or at most (/"least") -0.6 will be displayed along with regression information, whereas an item with a change of less than +0.4 or more (/"less") than -0.6 in self cost will be displayed as if there was no change whatsoever. If you expected large changes in your profile, choose large values to keep the report nice and short. If you expected only small changes, choose small values. If you are interested rather in increases in cost than in decreases, choose asymmetric values with a bias towards the decrease, if you are interested rather in decreases in cost than in increases, choose asymmetric values with a bias towards the increase.

Describing renamings

Before PerfReport can calculate the changes in cost and then decide (according to the above parameters) whether it should display regression information and what information to display, PerfReport has to match each symbol appearing in the older profile with the corresponding symbol appearing in the newer profile. This is most trivial if the symbol and library names are the same; PerfReport will use a (symbol name, library name) key to identify each function. Imagine however that from one to the next release of CMSSW it is decided to change the name of some class. In this case, PerfReport does not know the old and the new classes are related and displays only the new one, claiming it has disappeared from the cost list.

To prevent this from happening, you can provide PerfReport with the information that the name has changed and it will consider this when computing the correct matching. The description of such renamings has to be placed in the regression config XML in the <Renamings> section. The <Renamings> section may contain an arbitrary number of <Renaming> subelements. These in turn have the following structure:

<Renaming>
 <Search>...</Search>
 <Replace>...</Replace>
 <Part>...</Part>
 <Lookup>...</Lookup>
</Renaming>

The various elements have the following meaning and usage:

element meaning and usage
Search Here you provide the name which has changed. As usual, make sure you use &lt; for < and &gt; for >.
Replace Here you provide the name after the change.
Part Here you specify where in the part of the function names the change has occurred. The following values can be used:
  • FunctionName
  • ClassName
  • LibraryName
  • Anywhere
If the value is Anywhere, PerfReport will replace function names, class names and namespace names. Library names are not changed. If you want to change both library names and function names, provide two Renamings.
Lookup Here you specify the direction of the change. Admissible values are:
  • Prospective. This means that the string you provided in Search is the name of element in the older profile, and the string you provided in Replace is the name of the element in the newer profile.
  • Retrospective. This means that the string you provided in Search is the name of the element in the newer profile, and the string you provided in Replace is the element in the old profile.
It is important to understand that using Retrospective Lookup mode is not equivalent to swapping the strings in Search and Replace. The difference shows in cases where either after the renaming is applied, there are identical names in the profile, or where the set of functions in the older and newer profile differ.

The following graphic illustrates the process of matching symbol names in PerfReport. There are prospective changes from A to Ax and from func2 to func_2, as well as retrospective changes from Bx to B and from func_1 to func1.

renamings.png


PerfReport 1

WARNING

PerfReport version 1 is deprecated. Use it exclusively if you are forced to analyse profiles generated with the standard unpatched version of Callgrind. In any other case please use PerfReport 2.

Instructions for using PerfReport 1

Instructions for using PerfReport version 1

Review status

Reviewer/Editor and Date (copy from screen) Comments
KatiLassilaPerini - 15 Mar 2007 created template page
VincenzoInnocente - 16 Mar 2007 page content last edited
Robin Moser - 29 Mar 2007 page content last edited
JennyWilliams - 17 Aug 2007 moved deprecated PerfReport version 1 information to here

Responsible: VincenzoInnocente
Last reviewed by: RobinMoser - 22 Mar 2007

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng illu_collapse.png r1 manage 2.0 K 2007-08-16 - 14:48 UnknownUser illustrates the effect of a collapsing filter
PNGpng illu_nodeinline.png r1 manage 2.0 K 2007-08-16 - 15:02 UnknownUser illustrates the effect of the 'nodeinline' filter
PNGpng illu_prune.png r2 r1 manage 1.5 K 2007-08-16 - 15:05 UnknownUser illustrates the effect of the 'prune' filter
PNGpng illu_skip.png r1 manage 1.6 K 2007-08-16 - 15:03 UnknownUser illustrates the effect of the 'skip' filter
PNGpng illu_subtreeinline.png r1 manage 2.1 K 2007-08-16 - 15:03 UnknownUser illustrates the effect of the 'subtreeinline' filter
PNGpng renamings.png r2 r1 manage 39.3 K 2007-08-15 - 15:08 UnknownUser illustration of the name matching process for regression analysis
Edit | Attach | Watch | Print version | History: r34 < r33 < r32 < r31 < r30 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r34 - 2011-07-20 - VincenzoInnocente



 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback