I'm sorry that we haven't been able to follow up on the opreport -X
discussions until now. Between vacations, and conferences both Maynard
and I have been away from the office for most of July, but are
ready to get back to these issues.
Let me summarize the issues that you raised in previous posts:
1. Why are we generating array indexes to index into the detailTable
or symbolTable instead of using a more XML-like approach of using
We'll add the lookup id attribute to detailData and symbolData. The
XML consumer tools writers are free to ignore these and implement
symbolTable and detailTable as arrays if the tree lookup performance
is really bad.
2. Our syntax for collecting together sample count data for
multiple CPUs into a single comma separated list: count=",,12,34,,56"
Actually the full encoding of counts should have also included
syntax for events and masks. For example,
(cpu0_count:cpu1_count:..cpuN_count:1, ..., cpu0_count:...cpuN_count):mM
event0 ... eventE
An instance might look like: (4 CPUs, 3 events, 2 masks)
Your response to this is that it is too weird and I think you suggested
that we should use a class type that enumerates every combination of CPU,
My first reaction to your proposal was that it would explode the
size of the XML when --details is used but on further reflection
I think that explosion in XML size only happens if you get more
dense sample data. i.e. most of the instructions that have sample data
have data for multiple combinations of CPU, events, and masks. In my
very limited experience with oprofile profiles I didn't see this happen.
We'll put the class types into the schema and output the list of
all combinations of CPU, event, mask in some form and reference
these class identifiers as you suggest in the sample data.
If XML size becomes a bigger issue we might want to explore the above
encoding, or maybe have some option like, --dense, to cause opreport
to generate a more dense encoding of counts.
3. SummaryData is a weird, overly generic name. It should be renamed
I think Maynard explained in one of his mails that we have two
different XML elements to represent sample data, both of them contain
an attribute called "count". sampleData is a --details data point
with an optional source_line and source_file attributes; summaryData
is the aggregation of all the sampleData elements associated with
a container (Thread, Module, Symbol) and has no need for source_line or
If you don't think this distinction is useful, we could just define:
<xs:attribute name="class" type="xs:string" use="required"/>
<xs:attribute name="line" type="xs:nonNegativeInteger" use="optional"/>
<xs:attribute name="file" type="xs:string" use="optional"/>
4. Any file names should always be full paths.
5. The following XML although valid, is unusual and hard to access.
Maybe we should be using libxml to write out XML.
title="opreport -l session:dcnthr tgid:5590 -g -X "
We will change the code to use the xmlwriter interfaces for writing XML.
If you have further comments on any of the above issues, or any other
issues that I've missed, please let us know.