[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] UI for external analyses
|
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!
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.
I'll reply to your next email now for further details.
Cheers,
Genevieve