Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] UI for external analyses 


On 2016-02-23 10:42 AM, Genevieve Bastien wrote:

Hi Alex,

On 2016-02-22 14:59, Alexandre Montplaisir wrote:

Hi Geneviève,

Thanks for your input!

On 2016-02-22 10:17 AM, Geneviève Bastien wrote:

Hi Alex,

Sorry to come in late in that discussion. Here are my thoughts:

On 02/19/2016 02:59 PM, Alexandre Montplaisir wrote:


[...]




Thinking a bit more about it, one thing I like about the current
prototype, and just having the analyses listed under the trace in
general, is that it helps in discoverability. If it's not immediately
visible, the user might never find out the option exists.

But as you say, it should be separated from "normal" analyses. I kinda
like the idea of a separate sub-tree. It could be something like:

   mytrace

      +- Automatic analyses

      |     +- Kernel analysis
      |     +- CPU Usage analysis
      |     +- etc.
      +- On-demand analyses
            +- LTTng-Analyses CPU Top
            +- LTTng-Analyses IO Top
            +- Critical Path analysis (eventually!)
            +- etc.


something like that?

Why the eventually next to critical path?
The critical path, I think, is a good example of this new concept of on-demand/static analyses. The user enters some parameters (a thread, there could eventually also be a time range), then does an action to start the analysis. The result is then a static time-graph that shows the critical of the selected thread.
What if I wanted to look at the critical paths of two different threads at the same time? Today this is not possible, is it? But if we change the analysis to a on-demand/static analysis, we could run it multiple times with different input parameters, and look at the results of each run - each report - side-by-side.
Wait wait, so by what you went from calling "External analysis" to "on-demand analysis" to "static/report", you actually mean parameterized analysis? That's yet another orthogonal concept! We now have 3 dimensions! 

Woah woah not too quick! ;)
Let's settle on the latest terminology of "dyanmic analysis" and "static analysis" for now.
Since the dynamic analyses are run automatically, either if they are lazy-loaded or not, I don't think they can be considered parameterizable, because the user does not control directly when they start, so they cannot provide parameters (trace contexts, or others) to it. 

If we do a little breakdown:

Dynamic analysis:
- are started automatically (lazy-loaded or not)
- runs once for the whole trace/experiment
- outputs are dynamic views
- Dynamic views update their contents whenever the trace context, like visible time range, selected time range, etc., changes. 
- examples: Control Flow, Resource view, CPU Usage, etc.


Static analysis:
- are started manually by the user
- parameters may be provided, either retrieved from the trace context, or explicitly 
- can run just for a selected time range, depends on the analysis
- outputs are static reports
  - These reports can be saved, closed, re-opened
  - One report can supply multiple views
- examples: LTTng-Analyses wrappers, Critical Path


Did I forget anything?
I list Critical Path there, although right now it is considered a dynamic analysis like the others, eventually it could be moved to the new paradigm. It has always been a bit weird, for instance the analysis execute()'s again when a new thread is selected. It is the only one that works that way. I think converting it to a static analysis will fit better, see below.
The critical path creates a view, that could contain a button to trigger the analysis instead of just responding right away to a selection in the control flow view. And we could have many instances of that view pinned to a different tid.
I'd say the critical path is lazy, with dynamic output and parameterizable.
Today the critical path analysis/view are dynamic, because as soon as you select a new thread in the CFV, the view updates to show the information related to this thread.
When I think of that analysis as a static one, I'm thinking of the following workflow: 

- Select thread
- Manually run the Critical path analysis
- This generates a report
- Opening this report (can be opened automatically when ready) would show the view we have today. 
- That view can then be closed and re-opened at will
- The analysis can be run again on another thread, which will generate a new report, which can be opened side-by-side with the previous one
However, since the output is a timegraph view, it makes sense to keep it synchronized with the time stamp selections. So that view would be slightly "dynamic" in a sense. But where it is truly static is that its data model won't change afterwards.
If the critical path was a fully dynamic analysis like the others instead, it would work this way:
- Critical path analysis is run automatically, pre-computing the critical paths for all threads in the trace. - The view would update to show the contents for the current time stamp / thread selection
Right now, it is in a weird limbo between the two. Let's help it find a home :) 


Cheers,
Alex



I'll reply to your next email now for further details.

Cheers,
Genevieve

Back to the top