[
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