Implement about:tracing UI for the sampling profiler (trace-viewer part)

Implement about:tracing UI for the sampling profiler (trace-viewer part)

The design document of the sampling profiler is https://docs.google.com/a/google.com/document/d/1j39sbA9ECTwFFlxbhSD1EvJnGfYeS5EUJ05yxuku6VY/edit# 

The Chromium side CL is here: https://codereview.chromium.org/23556003/

BUG=241743
TEST=profiling_view_test.enableAndDisableContinuousSamplingTracing,
profiling_view_test.showContinuousSamplingTracing,
tracing_controller_test.showContinuousSamplingTracingCompleteFired,
analysis_results_test::displayValuesInDataRow,
analysis_results_test::displayValuesInDataRowOfSamplingTracing,
analyze_slices_test::instantiate_withMultipleSlicesToBeSorted,
analyze_slices_test::analyzeSelectionWithSlicesToBeSorted,
thread_track_test::sampleThreadSlices,
heading_track_test::headingTrackContents,
heading_track_test::headingTrackLinkFired

[haraken, 2013-09-03 06:53:00]

Now I added tests. PTAL.

[dsinclair, 2013-09-03 14:09:51]

My preference would be to move the enable/show of the sampling profiler into the
Record dialog.

With the current implementation we have two ways to enable profiling. What
happens if you enable the sampling profiler and then do a record? Will you be
able to see both sets of results in the same timeline?

I think a better way to do this would be to move the sampling profiling enable
button into the Record dialog, so you press Record, then at the bottom where the
record button is, we add a second 'run sampler' (or something) button. Pressing
'run sampler' would hide the record dialog, show the grey'd out background
saying tracing is in progress.

When the user wants to see the results they press Stop (as with regular
recording) and the timeline appears.

This would keep the two recording mechanisms the same in terms of flow, and make
it obvious that you can only do one or the other.

Thoughts?

https://codereview.appspot.com/13273043/diff/7001/src/about_tracing/profiling...
File src/about_tracing/profiling_view.css (left):

https://codereview.appspot.com/13273043/diff/7001/src/about_tracing/profiling...
src/about_tracing/profiling_view.css:13: .profiling-view .controls .save {
Why remove the margin on the save control?

[haraken, 2013-09-03 16:57:03]

Thanks Dan for reviewing!

> My preference would be to move the enable/show of the sampling profiler into
the
> Record dialog.
> 
> With the current implementation we have two ways to enable profiling. What
> happens if you enable the sampling profiler and then do a record? Will you be
> able to see both sets of results in the same timeline?
> 
> I think a better way to do this would be to move the sampling profiling enable
> button into the Record dialog, so you press Record, then at the bottom where
the
> record button is, we add a second 'run sampler' (or something) button.
Pressing
> 'run sampler' would hide the record dialog, show the grey'd out background
> saying tracing is in progress.
> 
> When the user wants to see the results they press Stop (as with regular
> recording) and the timeline appears.
> 
> This would keep the two recording mechanisms the same in terms of flow, and
make
> it obvious that you can only do one or the other.
> 
> Thoughts?

hmm, I have a mixed feeling.

- Basically, I'm assuming that the sampling profiler is always running. If a
user enables the sampling profiler, the user won't stop it. Specifically, I'm
assuming that the user enables the sampling profiler and then observes the
profiling results repeatedly. So, it's not a model of Record => Stop => Show.
The model is Enable => Show => Show => Show => .... In the near future, I'm
planning to enable the sampling profiler by default (at least on desktops). Then
the 'Enable =>' step will be gone.

- The sampling profiler can run (in background) with the normal tracing in
parallel. It's even possible to trace the normal tracing with the sampling
profiler.

Given the situation, I guess that:

- we can have the "enable sampling profiling" button and the "show sampling
profiling results" button in the about:tracing bar.
- once we enable the sampling profiling by default, we can remove the "enable
sampling profiling" button.

WDYT?

>
https://codereview.appspot.com/13273043/diff/7001/src/about_tracing/profiling...
> File src/about_tracing/profiling_view.css (left):
> 
>
https://codereview.appspot.com/13273043/diff/7001/src/about_tracing/profiling...
> src/about_tracing/profiling_view.css:13: .profiling-view .controls .save {
> Why remove the margin on the save control?

Will restore.

[nduca, 2013-09-03 19:58:06]

I understand your workflow. However, whatever we land should make it possible to
monitor tcmalloc heap dumps in the background and get snapshots. Or have it
monitoring a lightweight set of tasks in the background and when there is UI
jank, pull the latest ringbuffer for a slow report. By focusing on sampling, we
preclude those use cases and accumulate some technical debt against someone else
who wants to accomplish those use cases.

I'd like to discuss how to implement this not as a sampling specific feature,
but rather just a new set of interfaces on trace_controller.h etc that toggles
tracing between a monitoring mode and a start/stop mode. In both monitoring mode
and regular mode, there is a category filter. Possibly also a set of monitoring
options.

The sampling thread is, ideally, just an option on the tracnig controller.

Your workflow is just:
- put the trace controller in monitoring mode, set the category filter to
exclude everything, and turn on the sampling thread
- when in monitoring mode, replace the record button with a "grab current"
button

Just some thoughts. As it turns out, I'm contemplating a pretty big rewrite of
the trace controller and the about:tracing side of the js, so it might be
possible for me to help make some of these changes so that you can still get
your goals accomplished in reasonable timeframe.

[haraken, 2013-09-03 20:04:42]

> The sampling thread is, ideally, just an option on the tracnig controller.
> 
> Your workflow is just:
> - put the trace controller in monitoring mode, set the category filter to
> exclude everything, and turn on the sampling thread
> - when in monitoring mode, replace the record button with a "grab current"
> button
> 
> Just some thoughts. As it turns out, I'm contemplating a pretty big rewrite of
> the trace controller and the about:tracing side of the js, so it might be
> possible for me to help make some of these changes so that you can still get
> your goals accomplished in reasonable timeframe.

Sounds reasonable to me. I agree that the design you described above should be
the future. I'd like to discuss how to get there in reasonable timeframe :)

[haraken, 2014-07-02 15:30:22]

This CL was landed. Closing.