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

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

Sounds fair, I would suggest AnalysisDataProviders, but plain old
analyses work too.

Let's have fun and write code!

Br

Matthew


On 17-10-12 11:43 AM, Geneviève Bastien wrote:
> 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
> _______________________________________________
> 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