Re: [tracecompass-dev] Trace type vs trace profile

[Geneviève Bastien <gbastien@xxxxxxxxxxxx>]

Well well Matthew,


Your capabilities look awefully like plain old analyses. Shall we then
skip that concept and go straight to the "analysis"? One analysis can
have many sub-analyses, like the callstack already does with the
callgraph and execution graph with the critical path.


We can just

1- drop the link between trace type and analysis (or keep it as a hint
and/or legacy)

2- play with the analysis requirements a bit.

3- [finally] stop showing all "applicable analyses" under the Views tree
(since they would all be "applicable") and show just the ones that
correspond, to which the user can add their own, knowing what's in the
trace?

We can try that with the analyses in the incubator, there's enough of
those, and get some feedback from there.


Counter-counterthoughts?

Geneviève


On 2017-10-12 11:04 AM, Matthew Khouzam wrote:
> This makes a lot of sense since traces can have one type, that is how we
> parse it, but many profiles.
>
> Consider that you can have event aggregators, event sources and programs.
>
> Program 1 follows the opentracing api
>
> Program 2 is a finstrumented program
>
> Program 3 is a js program running in chrome
>
> Program 4 is running an OpenGL frontend
>
> Then there's the kernel.
>
> So now, we have
> 1, 3, and 4 that generate a json trace
> 1, 2, and the kernel generate a ctf trace
>
> we make an experiment with
> 1(ctf), 2, 3, 4 and the kernel trace.
>
> The parsers are fine, but how do we know which analyses to assign to
> which trace.
>
> That being said, trace profile is ambiguous since traces like LTTng have
> profiles already. Maybe we can discuss different names.
>
> I like Capabilities.
>
> So 1 would have "span", "callsite" and "call stack" capabilities
> 2 would just have "call stack"
> 3 would have all of one as well as "counter" and "Memory"
> 4 would have "request"
> and kernel would have "kernel" which hopefully will be broken down into
> "process/thread" "CPU state", "Run queues", "IO", "Memory", "swapper"...
>
> The "Capabilities" should not be coupled to a file format.
> That way we can test with arrays or XML files without having to make
> "kernelTraceStubs"...
>
> So I really like this idea, should it be incubating?
>
> Counterthoughts?
>
> Matthew
>
> On 17-10-12 10:34 AM, Geneviève Bastien wrote:
>> Hi all,
>>
>> Here's a topic I've been munching the past months. I think we've reached
>> the limits of the concept of "trace type", or at least, it's being used
>> for more than it should.
>>
>> A trace has one and only one "trace type" and analyses are linked to the
>> trace type. But that trace type refers more to the trace format, ie how
>> to read the trace, while the analyses relate to the content of the
>> trace. And the more trace types we have, the more their content overlap
>> and analyses from other trace types apply.
>>
>> To name a few example, an LTTng JUL Trace from a Trace Compass
>> application has the same events/fields as a trace-event trace. A
>> perf2ctf trace has both kernel and userspace data.
>>
>> So I'm proposing to add the concept of "trace profile", which will
>> correspond to the content of the trace. A trace can have many profiles,
>> some profiles can be guessed from the trace type, especially if it has
>> pre-defined events. And the user  can add profiles to her trace. The
>> analyses would be linked to a profile instead of a trace type.
>>
>> I'll experiment with it in the incubator, but that concept should
>> definitely be in the core.
>>
>> Thoughts?
>>
>> Geneviève
>>
>> _______________________________________________
>> tracecompass-dev mailing list
>> tracecompass-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev