Rob Fowler wrote:
>> On Mon, Feb 27, 2006 at 05:53:44PM -0600, Maynard Johnson wrote:
>>> Maynard Johnson wrote:
>>> Ping. Has anyone had any time to look at this? John, did I answer
>>> your questions with the revisions I made?
>> I just don't have the time to look at this right now :(
> I've been meaning to send a reply to this, to the discussion
> about the API (C: yes, C++: a nightmare of compatibility issues),
> and reply to a message from John with questions about about design
> decisions I described in my Dec 21 2005 message to this list. I
> will try to discuss this at length next week.
> Unfortunately, I've been swamped in other stuff and will
It must be contagious. The swamp is up to my chin, too. :-)
> be for at least another week. In the interest of timeliness,
> though, here are some short comments:
> My impression, admittedly with only a brief scan, is that your
> format would be fine for high level reports, it will be way too
> verbose for reporting detailed profiles of really big programs.
> For example, in
> <Event Event_ID="PM_INST_FROM_L35_GRP7" unit_mask="0x0"
> setup_count="60000" sample_count="35" />
> everything except the sample count is redundant wrt every other
This was simply a mistake in the hand-coding of the example XML. The
schema defines Event such that unit_mask, setup_count, and sample_count
are optional and should only be inserted into the resultant XML instance
as appropriate. I concede the point that including the entire string of
the event ID for each sample would be unnecessary. This could be easily
fixed by including an 'id' attribute in Event. Then, in the singleton
SampleInfo defined for the entire profile, the Event elements would have
their 'id' attribute set to some unique value. Then the SampleInfo
elements representing actual samples could use the 'id' to refer to the
appropriate pre-defined Event. I'll work on this change (as soon as I
come up for air) and post the revised XML schema.
> line that reports the same event.
> We defined a very lean format for our use. See
> for a description of an older version.
Your very lean approach to element and attribute naming makes it
difficult for me to say how close we are conceptually. But I suspect
that your PGM element is very close to my Module element. The element
and attribute names I chose for the proposed schema are more or less
self-describing. But while such verbose names may be useful for
discussion, you make a good point that this would result in
unnecessarily large XML instances. Once we agree on structure, the
names should definitely be abbreviated.
> Our approach is not to extract everything to XML. Even
> with the lean XML format for profile data, there is still
> a substantial dilation in the size of the data. We don't
> want to do this to every executable image on thousands of
> nodes of a huge cluster. Hence, we wrote a tool
> that extracts detailed profiles only for designated images.
My intention with the proposed schema design is that it would be
flexible enough to include as little or as much as what the user asks
for in their profile spec passed into opreport.
Thanks for the constructive comments.
> Rob Fowler
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> that extends applications into web and mobile media. Attend the live
> and join the prime developer group breaking into this new coding
> oprofile-list mailing list