[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] UI for external analyses
|
On 2016-02-22 09:29 AM, Bernd Hufmann 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?
Not clear yet how you will distinguish between Automatic and
On-demand. Are automatic analyses analyses that are marked as
automatic in the analysis plug-in extension and are run when opening a
trace? And the On-demad analyses are all analyses that are either
external (e.g. LTTng Analysis) or are "normal" analyses that are not
run automatically when opening a trace?
Actually no, the "automatic" in the extension point is something else.
The CPU usage view runs whenever its output is requested, but the user
doesn't have to provide any parameters or anything. We'd be adding a
third type of analysis here:
Automatic analyses, runs by default (like the Kernel analysis)
Automatic analyses, lazy-loaded (like the CPU usage analysis)
On-demand analyses (like the LTTng-Analyses runners)
The big difference of the new 3rd type is that their output are not
straight views, after they are run, they produce *reports*. These
reports can then be opened, exported, deleted, etc.
Perhaps "on-demand" is also confusing :/
If yes (to both questions) then your picture on top is incorrect. The
CPU Usage analysis is On-Demand. It is only executed when the CPU
Usage view is opened or if the CPU usage is already open when a trace
is opened.
[...]
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.
I think, it's quite essential to have the data-driven aspect right
from the beginning and not having it as a future step. The integration
between command-line analyses and Trace Compass is meant for users to
easily use their custom scripts together with Trace Compass without
having to write Java. Having to write a Java shim for each available
analysis, the user would not do that. They would rather write the
analysis in Java to begin with or stick to the command-line.
My current mandate is to integrate the LTTng-Analyses project into Trace
Compass. Supporting integration for any generic command-line analysis
would of course be useful, but that is a much bigger venture. I don't
think I will have the time to do this this year. But of course I will
gladly help anyone who would work on that.
Cheers,
Alex