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 
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. 



Also, there appear to be a terminology issue with automatic vs on-demand
analyses, external analyses, etc. So it would be important to define
those terms. Right now, we have 2 types of analyses:

* Automatic: Run whenever a trace is opened, it does not wait for a view
or user action to schedule it
* On-demand (automatic set to false in extension point): Some other
action schedules the analyses, like opening a view, or selecting an
entry in a view.

 From your first post, there seems to be an orthogonal concept of static
vs dynamic analyses:

* Dynamic: follow user action, time ranges, etc
* Static: Generated once on the whole trace or time range and that's it.
That is where your "external analyses" fit. Why not call them simply
"reports" or "analysis reports".

So in your tree up there, you would have "Analyses" (both automatic and
on-demand) and "Reports" (on-demand, but could also be automatic) for
static external analyses.
Yep as I explained in my reply to Bernd, it is orthogonal to the current notion of on-demand/lazy-loaded analyses. "Static analysis" is not bad, though I'm not sure if it's intuitive enough...
You are right about the reports, we should also display them somewhere so that they can be re-opened, deleted, managed in some way. However, don't forget it's possible to run the same analysis multiple times to get different reports, like in the example above. So we would need both, the list of analyses that can be run, and the reports that were generated. What would be the best way to show them? 


trace
 +- Automatic/Dynamic analyses
 |   +- Kernel analysis
 |   +- CPU Usage analysis
 +- On-demand/Static analyses
     +- LTTng-Analyses CPU Top
     |   +- Report 1
     |   +- Report 2
     +- LTTng-Analyses IO Top
     |   +- Report 1
     +- Critical Path analysis
         +- Report 1



or rather

trace
 +- Automatic/Dynamic analyses
 |   +- Kernel analysis
 |   +- CPU Usage analysis
 +- On-demand/Static 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



?




And of course, the Properties view would be a nice place to put extra
information about each analysis.

Since recently, analysis can provide properties, so it would be a few
liners to just add the help text to those properties for a start.


This is not ideal, because it's confusing which analysis are
supposed to be run manually, and which are just there for listing
their outputs. A potential alternative would be to have a new "Run
External Analysis" option, from the context menu of the *trace*,
which would open a dialog to handle all available external analyses.

Also, we'd probably need a new name instead of "External Analysis".
These may not even be external eventually, they could be defined in
Java, shipped with Trace Compass, and be able to be called on demand
by the user.

Good point. External doesn't fit.

Yes, I'm warning up to the idea to "Automatic analysis" vs. "On-demand
analysis". Other ideas?

Even in the current prototype, the analysis are defined in Java. Since
there is no auto-discovery yet, each available analysis has to be
defined manually.


Thoughts?


One thing is needed a way to manage the external analysis (I mean the
ones that actually external). I'm thinking of a dialog like the
"Manage Custom Parsers" or "Manage XML analyses" where users can
import/export/delete/edit external analysis.

Indeed, it would be great to have "Data-driven on-demand analyses" no? :)

But for now, as mentioned above, there needs to be a Java shim for
each available analysis, with a corresponding extension point entry. I
would see data-driven-ness as a future step.

Like Bernd said, the future could be here sooner. We can discuss it when
you reach this point, but I think it wouldn't be too hard to add
"data-driven reports" sooner than later. It might even help generalize
what is already available and make everything data-driven!! no Java shim
anywhere (you can have builtin XML analyses come with plugins).
I think we first need to clarify the whole notion of dynamic/static analyses and reports. I know them main point of interest here are the LTTng-Analyses, but "static analysis" does not necessarily imply "external script".
Once we have that worked out, then we can start looking at how "external static analyses" could be defined. Instead of Java shims, should they be XML shims that wrap around existing scripts? Or should we just point to a directory of executable scripts, and mandate that the scripts themselves following a certain output format? I would lean towards the latter, because we already have a pseudo-spec [1] of the output format for LTTng-Analyses. 


Cheers,
Alex
[1] The so-called LAMI format, not-yet-final version at https://gist.github.com/eepp/eef46aba8209a804cb97 



Cheers,
Geneviève

Back to the top