[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] UI for external analyses
|
Hi Alex,
Let's just forget about the Critical Path case for now, we could argue
forever. It works but not in the perfect user-friendly way, we'll see
how it evolves and put it somewhere then.
On 23/02/16 03:37 PM, Alexandre Montplaisir wrote:
On 2016-02-23 11:11 AM, Genevieve Bastien wrote:
Hi Alex,
This is the 2nd of 2 replies. The other one should be read first.
On 2016-02-22 15:51, Alexandre Montplaisir wrote:
[...]
I discussed this a bit more with some colleagues, and and we
realized the list of Dynamic analyses is not really useful for the
end-user ; what they use is the list of Views they can open, which
are shown currently under each analysis they belong to. But the user
doesn't have to know that the Control Flow view comes from the
Kernel analysis, they are only interested in the output.
So, what if we stopped showing the (dynamic) analyses altogether? A
big advantage is that we could use the name "Analysis" for the only
type of analyses the user will care about: the static ones! So the
tree could look like this:
trace
+- Views
| +- Control Flow view
| +- Resource view
| +- CPU Usage view
+- Analyses
| +- LTTng-Analyses CPU Top
| +- LTTng-Analyses IO Top
| +- Critical Path analysis
+- Reports
+- CPU Top Report 1
+- CPU Top Report 2
+- IO Top Report 1
+- Critical Path Report 1
In the code we could still refer to dynamic/static analyses, but the
only analyses we would show to the user would be the static ones,
since they are the only one they can act upon. How does it sound?
Yes to displaying the views directly! Ideally they would not even be
under the trace (like in other trace viewing tools) and even show
thumbnails (that's on my wishlish). Anyway, what's interesting here
is that views are one type of output (the only type of output
available in trace compass so far).
Ok, I am working at the moment on adding new nodes in that tree for
the new static analyses and reports. I was going to keep a "Dynamic
analyses" sub-tree for the moment, but should I go ahead, remove the
list of analyses and just list the views?
I'd say yes for a start. You can google "Windows performance analyzer"
and look at images, the way they display their view is interesting. But
that's for later probably.
So here's a thought. Maybe what's under "Analyses" should be another
type of output, linked to the corresponding [parameterized] analysis.
And after one of those output is generated, they would be saved under
a trace's supplementary files and appear under report (that behavior
could be defined in the new [something]Output implements
IAnalysisOutput class).
Dynamic views and reports don't behave the same, I am not sure if both
should be IAnalysisOutput's. Today the only IAnalysisOutput we have
are dynamic views. I remember we often gave the "command line output"
example as another possible type of analysis output, but in
retrospect, that would fit better as the output of a static analysis,
so a report.
From my point of a view, a report is what was meant as another type of
analysis output. But I guess at this point, I would need to see some
code to be a better judge. Maybe what I think a report is is not what
you think/know it is.
I think we all know what we want, it's just a matter of deciding what
IAnalysisOuput actually means ;)
And yes, reports could be saved as trace supplementary files, that'd
be the perfect place for that.
The critical path view would be under the Views header, but the
various pinned instances of it could appear under the "Reports"
section. But in the critical path case, (unlike your
analyses/reports? or at least my idea when I think of a report?),
when you close the view window, the data is not saved and you have to
re-do the analysis if you want to see the critical path again.
As I said in my previous email, I don't think the critical path view
should be considered a dynamic view eventually. You would run a static
analysis (what will be called "Analysis" in the UI) and it generates
the report. So if you run it multiple times for different threads, you
would obtain something like this:
trace
+- Views
| +- Control Flow view
| +- Resource view
| +- CPU Usage view
+- Analyses
| +- LTTng-Analyses CPU Top
| +- LTTng-Analyses IO Top
| +- Critical Path analysis
+- Reports
+- Critical Path for TID 1000
+- Critical Path for TID 1001
+- Critical Path for TID 1002
When you first open the trace, you get this tree without anything
under Reports. You still have full discoverability of what can be done
with your trace. The things under Views are readily available because
it was already pre-computed (the dynamic analyses have run, or will be
run lazily). The things under Analyses require some parameters, so
they are only run as the user requests it. If the user runs the
Critical Path analysis, he will see "Critical Path for TID 1000"
showing up. We could perhaps open new reports automatically, we'll
have to see.
Does that clarify a bit what I mean by "report"? ;)
I think it does. So a report is not "just" a textual output that you can
print on a 8 1/2 x 11 page. A report can contain views or rather
viewers, xy-charts, tree viewers, etc that can be dynamic with time
selection, etc. but statically pinned to some user action/selection that
parameterized its execution. "Report" might not be the right word again,
but having no other suggestion, you can keep it as good enough.
It seems we agree on the analyses/views separation, as far as
LTTng-analyses are concerned. For the rest, I need more information to
continue this discussion productively. See what a "report" really is.
I'll see you on gerrit or github ;-)
Cheers,
Geneviève
