Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
226933002:
Convert 'perf script' output to about:tracing json. (Closed)
|
Created:
6 years, 8 months ago by ojan Modified:
6 years, 8 months ago CC:
chromium-reviews Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionConvert 'perf script' output to about:tracing json.
This is a script creating json for importing into about:tracing
from a run of the Linux perf command.
I toyed with the idea of creating an intermediary json format
for CPU profiles and then teaching about:tracing to understand that,
but I decided it'd be better to keep things simple and not
have about:tracing need to support a new trace format.
Patch Set 1 #
Total comments: 14
Messages
Total messages: 10 (0 generated)
This is a surpsing amount of code. :) https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... File tools/convert_perf_script_to_tracing_json.py (right): https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:16: # samples instead of ms as the units. The samples themselves can sorta represent 0.1ms or whatever the sampling frequency is. https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:18: def strip_to_last_paren(line): I'm surprised you didn't just use a regexp to match the whole line? https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:31: # Strip function arguments. Yeah, I think a regexp would be more readable, maybe?
https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... File tools/convert_perf_script_to_tracing_json.py (right): https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:126: trace_data.append({ Crazy. When I started down this path I just used immediate events and didn't try to build a tree in the tracefile corresponding to teh stack traces. I guess that's kinda neat though, but I would expec these stacks to be very deep.
https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... File tools/convert_perf_script_to_tracing_json.py (right): https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:16: # samples instead of ms as the units. On 2014/04/05 00:03:13, eseidel wrote: > The samples themselves can sorta represent 0.1ms or whatever the sampling > frequency is. The perf script output doesn't say what the sampling frequency is. Maybe there's some other way to get at that? Personally, I prefer knowing the number of samples in my profiles to the number of ms, but I think it'd be good to give control over that if we have the information. https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:31: # Strip function arguments. On 2014/04/05 00:03:13, eseidel wrote: > Yeah, I think a regexp would be more readable, maybe? I had a lot of trouble coming up with a regexp that did what I wanted...so I gave up and wrote this. Open to suggestions. https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:126: trace_data.append({ On 2014/04/05 00:05:09, eseidel wrote: > Crazy. When I started down this path I just used immediate events and didn't > try to build a tree in the tracefile corresponding to teh stack traces. I guess > that's kinda neat though, but I would expec these stacks to be very deep. What are immediate events?
If you wanted to take this a step further, trace-viewer has a trace2html script (and associated build/trace2html.py file). Given the .json file you generate, you could have this script run trace2html on the json and produce a standalone HTML file. Then you can just open that instead of having to do the whole go to chrome://tracing and load the file dance. https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... File tools/convert_perf_script_to_tracing_json.py (right): https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:126: trace_data.append({ On 2014/04/05 00:13:50, ojan wrote: > On 2014/04/05 00:05:09, eseidel wrote: > > Crazy. When I started down this path I just used immediate events and didn't > > try to build a tree in the tracefile corresponding to teh stack traces. I > guess > > that's kinda neat though, but I would expec these stacks to be very deep. > > What are immediate events? Immediate events are drawn as a line, instead of a block in the UI. There are 3 types, global, process and thread. The type, bascally, describes how tall the line is. A global line is drawn the height of the UI, the process lines are a full process block and a thread line will be one slice high. https://docs.google.com/a/chromium.org/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYM... https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:140: trace_data.append({ I think, although I maybe mistaken, you could use a complete event here as well. As long as the timestamps are in the right order I think it will do the UI correctly. (Although, you'd need to test it to be sure)
can you share an example input & output file for this? maybe via email or something? i'd like to fiddle around with the file locally to get a feel for the data set...
https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... File tools/convert_perf_script_to_tracing_json.py (right): https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:16: # samples instead of ms as the units. On 2014/04/05 00:13:50, ojan wrote: > On 2014/04/05 00:03:13, eseidel wrote: > > The samples themselves can sorta represent 0.1ms or whatever the sampling > > frequency is. > > The perf script output doesn't say what the sampling frequency is. Maybe there's > some other way to get at that? > > Personally, I prefer knowing the number of samples in my profiles to the number > of ms, but I think it'd be good to give control over that if we have the > information. In my experience the perf sampling interval is quite variable and hard to convert to time. Perf has a "period" field in every sample, that has to be used as a weight. This is how "perf" calculates %ages. perf script doesn't support the "period" field, but I added it locally.
https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... File tools/convert_perf_script_to_tracing_json.py (right): https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:126: trace_data.append({ On 2014/04/08 02:28:36, dsinclair wrote: > On 2014/04/05 00:13:50, ojan wrote: > > On 2014/04/05 00:05:09, eseidel wrote: > > > Crazy. When I started down this path I just used immediate events and > didn't > > > try to build a tree in the tracefile corresponding to teh stack traces. I > > guess > > > that's kinda neat though, but I would expec these stacks to be very deep. > > > > What are immediate events? > > Immediate events are drawn as a line, instead of a block in the UI. There are 3 > types, global, process and thread. The type, bascally, describes how tall the > line is. A global line is drawn the height of the UI, the process lines are a > full process block and a thread line will be one slice high. > > > https://docs.google.com/a/chromium.org/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYM... The heading fragment doesn't seem to work. Searching the doc for "immediate" doesn't find any hits. In either case, from your description of how they're drawn, I'm not sure why we'd want to use immediate events here. IMO, the whole point of this is to get the tree view of the samples. https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:140: trace_data.append({ On 2014/04/08 02:28:36, dsinclair wrote: > I think, although I maybe mistaken, you could use a complete event here as well. > As long as the timestamps are in the right order I think it will do the UI > correctly. (Although, you'd need to test it to be sure) I'm not sure what you're suggesting...how would the children be nested beneath this function if using a complete event? Or are you just suggesting changing the phase to "X"?
https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... File tools/convert_perf_script_to_tracing_json.py (right): https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:126: trace_data.append({ On 2014/04/08 19:38:40, ojan wrote: > On 2014/04/08 02:28:36, dsinclair wrote: > > On 2014/04/05 00:13:50, ojan wrote: > > > On 2014/04/05 00:05:09, eseidel wrote: > > > > Crazy. When I started down this path I just used immediate events and > > didn't > > > > try to build a tree in the tracefile corresponding to teh stack traces. I > > > guess > > > > that's kinda neat though, but I would expec these stacks to be very deep. > > > > > > What are immediate events? > > > > Immediate events are drawn as a line, instead of a block in the UI. There are > 3 > > types, global, process and thread. The type, bascally, describes how tall the > > line is. A global line is drawn the height of the UI, the process lines are a > > full process block and a thread line will be one slice high. > > > > > > > https://docs.google.com/a/chromium.org/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYM... > > The heading fragment doesn't seem to work. Searching the doc for "immediate" > doesn't find any hits. > > In either case, from your description of how they're drawn, I'm not sure why > we'd want to use immediate events here. IMO, the whole point of this is to get > the tree view of the samples. Sorry, I should use the right words, we call them instant events, in the trace-viewer side. https://codereview.chromium.org/226933002/diff/1/tools/convert_perf_script_to... tools/convert_perf_script_to_tracing_json.py:140: trace_data.append({ On 2014/04/08 19:38:40, ojan wrote: > On 2014/04/08 02:28:36, dsinclair wrote: > > I think, although I maybe mistaken, you could use a complete event here as > well. > > As long as the timestamps are in the right order I think it will do the UI > > correctly. (Although, you'd need to test it to be sure) > > I'm not sure what you're suggesting...how would the children be nested beneath > this function if using a complete event? Or are you just suggesting changing the > phase to "X"? We create the nested slices based on timestamps not based on nesting. I believe you could just output a "ph": "X" here and drop the "ph": "E" event below. (It doesn't really matter all X events do is decrease the number of events we have to emit, it is functionally equivalent to a B/E pair for one X event.)
In either case, I'm going to close this. It sounds like Nat wants to integrate sampling data more directly into traceviewer. While some bits of this python code might still be needed for that, it won't look much like the current patch. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
