From: Maynard J. <may...@us...> - 2006-07-05 23:04:40
|
John Levon wrote: > On Fri, Jun 30, 2006 at 01:28:43PM -0500, Maynard Johnson wrote: > > >>>You didn't comment on this. I can see the argument for the hierarchical >>>approach for processes and threads, in fact, now you remind me. But >>>event num, mask, CPU etc all need to be like I describe above, I think. >> >>Dave had actually investigated this approach at one point, but >>eventually backed away from it. IIRC, the reason he didn't stick with >>it was because he (and others who reviewed the schema) felt it important >>to place the sample data out of line from the >>Process->Thread->Module->Symbol elements. This doesn't seem that big a >>deal when the XML instance includes only basic sample data, but when the >>user asks for --details and/or --debug-info, the amount of data >>explodes. It's easy to see then why having summary data at the 4 levels >>of the hierarchy described above would be beneficial to a tool consuming >>the XML. The tool could actually display the top-level information >>while parsing the rest of the file for the detailed sample data. > > > I'm not really talking about the summary data at each level, but the > layout of how you're hard-coding stuff... please review my example... In the generation of XML, we want to output all the sample data available. As I understand it, the profile classes are used as a means of processing the data into merged chunks that can be easily displayed in the column-based report. Nevertheless, we could still use something akin to the approach you suggest. But instead of there being separate class types, there would be just one type, with an instance for each event_num/cpu/(optional)unit_mask combination. I must admit that since the processors I'm familiar with don't use unit masks, I'm not sure how well the unit mask data fits in here. If there are an arbitrary number of unit masks for any given event, then this technique won't work. Regards, -Maynard > > regards > john |