Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Generic callstacks / callgraphs / flamegraphs

Hi Geneviève,

As you know, I am currently working on generalizing the time graph
views, by splitting the view model from the presentation layer. My first
target is the Control Flow View (and probably the Resource View at the
same time, since it's based off the same data). But I can easily see the
Callstack view fit into that model, since it is just a specialized
statesystem-based time graph view.

Your ICallstackProvider could become a subclass of
"StateSystemModelRenderProvider" [1], which would then populate its
corresponding Callstack View. This would avoid duplicating all the
view's logic. Then ICallstackProvider could provide all the downstream
flexibility you want. It would also be a good occasion to make sure the
*ModelRenderProvider classes provide sufficient functionality.

I should have a prototype ready over the next week, we can discuss it
further at that point.


[1] WIP prototype (lots of fixmes etc. remaining):

The implementation for the Control Flow would look like something like this:

(note that both of these are *core* classes, no UI dependencies at this

On 2016-09-08 09:52 PM, Geneviève Bastien wrote:
> Hi all,
> Callgraphs and flamegraphs were added recently to Trace Compass. This is
> such a great news that I want it for all my analyses!!
> Some use cases: sql queries and functions calls for a web request,
> execution stacks of threads used by the views of Trace Compass, a
> user-defined callstack from a ust-trace.
> So in the next weeks, I'll be working on making callstacks and
> callgraphs and their associated views more generic. I have a few patches
> on gerrit under the topic "for_jul_analyses callstack" [1] but they are
> not quite ready for review. Here is the plan:
> 1) Add a ICallStackProvider interface, implemented by the current
> CallStackAnalysis class that will provide CallStack objects that will
> describe where to get the callstack from [in the state system for now]
> 2) Make the CallGraphAnalysis use those ICallStackProvider and their
> CallStack(s) instead of the CallStackAnalysis directly and make sure all
> the views still work.
> 3) The current call stack analysis has a hierarchy process ID -> thread
> ID -> callstack where process IDs and thread IDs are conveniently
> integers. But that does not cover all the use cases. So instead there
> will be levels of grouping where a callstack can have as many levels as
> it wishes. The current case would have 2 levels (Process and threads)
> along with the final callstack level that has to be there. The current
> callstack will still work as it does now with the symbol resolution.
> 4) Add support of XML-defined callstacks, where an XML analysis will
> fill a state system with callstack-like data and will provide it as
> callstack to the views.
> 5) Fix the flame graph so that there is more than one level of grouping
> that can be shown (now is only threads, we don't have the process level)
> 6) Make it possible for callgraph to use any of the levels for
> aggregation, as requested by the user (right now, statistics are
> aggregated per thread only)
> 1 and 2 are done, as well as 4, but it lacks 3 to be entirely
> satisfactory. Any thoughts? Comments? Additional requirements?
> Best regards,
> Geneviève
> [1]

Attachment: signature.asc
Description: OpenPGP digital signature

Back to the top