Trace Compass/Design Documents/Project View

This page presents a proposal to reorganize the Project View and Trace Compass projects

Current implementation

There are various limitations to the current implementation:

• A Trace Compass project type is required. This makes it hard to integrate with other project types, for example opening traces while working in a CDT project. Only adding the project nature does not seem to work.

See the discussion in https://dev.eclipse.org/mhonarc/lists/tracecompass-dev/msg00412.html

• Experiments are second-class citizens. Most analyses do not work with experiments, only with single traces. Also the name "experiment" is not particularly intuitive.
• Analyses are listed under the trace. This is useless information for the user, and clutters the view. The list of views however is useful for the user.
• A new type of "on-demand" analysis is coming up. Unlike our standard "dynamic" analyses, these new on-demand ones will require user interaction. How should they be presented to the user?

Proposal

The proposal consists of reorganizing the Project View hierarchy into the following one:

- (Eclipse Project)
  +- Trace Collection 1
    +- Traces
      +- Trace 1
      +- Kernel Trace 2
      +- Kernel Trace 3
    +- Bookmarks
    +- Analyses
      +- Lttng-Analyses IO Top
      +- Lttng-Analyses Frequency Top
      +- Custom Analysis A
    +- Reports
      +- Frequency Top 1
      +- Frequency Top 2
    +- Views
      +- Control Flow view
      +- Resource view
      +- CPU Usage view

Trace Collection as the base element

"Experiment" would be renamed to Trace Collection, or Trace Set. This would be a new type of resource that could be part of any Eclipse project. There would always be a trace set, even for only one trace (although importing a single trace could create the trace set automatically).

The whole Trace Compass project type would be removed.

Traces

The Traces sub-tree would simply be the list of traces present in the trace set, just like traces are currently part of experiments.

Adding/removing traces after analyses have been run and reports generated would have to be thought about. Mark the relevant reports "dirty"?

Bookmarks

The current concept of bookmarks would be extended to apply to the whole trace collection. This way, existing bookmarks could point to locations in new traces in the collection as they are added.

Analyses

The list of on-demand analyses the user can run, which will generate reports.

Very important to note: this sub-tree would be used to list the on-demand analyses, like the LTTng-Analyses integration. The previous list of dynamic analyses would be removed (only the views are kept).

Reports

Reports are the output of on-demand analyses. As analyses are run, reports are generated and added to this list. The user can then open them, export them, delete them, etc.

A report can be a view or a set of view that contain the results of the analysis that was run.

Views

The list of views that can show information about this trace. These elements exist currently, but are located under the name of the analysis that populates them.

Points of discussion

The following points were mentioned so far:

Categories for views and analyses

Since the list of views and analyses could get quite long as more analyses are implemented, should they be separated in categories, like CPU, I/O, Network,... ?

Should views/analyses be able to belong to more than one category? This is more flexible, but more complex to manage, both for the developers and users.

For views, there is already the concept of category in Eclipse views, and the Show View... dialog uses these categories to organize them. This could be re-used here. (Can Views be in more than one category though?)

For analyses, the category would have to be added to the analysis extension point.

Reports under the analysis name

Should reports be under their own sub-tree element, or under the analysis that generated them?

Importing vs. Opening traces

A current use case is to import archives with a large number of traces, navigate in the hierarchy of directories, and only open a few traces. We do not want to start indexing all the traces because there are too many. This use case should remain possible with the new paradigm.

Perhaps change the import operation to import the archive contents as standard Eclipse resources, and then having the option of adding some of the traces to a new or existing trace set?

Future steps

Since this is a rather large undertaking, the changes could be brought in iteratively. The implementation steps could look like this:

• Re-organize the elements under the current Trace elements.
  • Stop showing the analyses, only the views
  • Add a sub-tree for on-demand analyses and reports
• Investigate and make sure all current analyses (dynamic and on-demand) work with experiments.
• Remove the Traces project element, always create experiments even for only one trace (ideally automatically when needed).
• Introduce the new Trace Collection resource, based on existing experiments.

For Neon

Most of it won't be ready for Neon, however the LTTng-Analyses integration would be really great to have. This requires some minimal changes, at least adding a sub-tree element for on-demand analyses and reports.

How should the View look like in Neon?

Proposal 1

Keep the current tree as-is, add sub-trees for Analyses (External? On-demand?) and Reports.

 Traces
   - kernel
     - CPU Usage
       - CPU Usage View
     - Kernel Analysis
       - Control Flow View
       - Resource View
     - Analyses
       - LTTng-Analyses
     - Reports

Proposal 2

Move the current list of analyses to a new sub-tree, and introduce the other new subtrees.

Again, naming will be very important, we probably do not want to introduces names that will be removed soon after.

 Traces
   - kernel
     - Views(?)
       - CPU Usage
         - CPU Usage View
       - Kernel Analysis
         - Control Flow View
         - Resource View
     - External Analyses
       - LTTng-Analyses
     - Reports

Proposal 3

Complete the removal of the list of dynamic analysis, and only show the views.

This would probably be ideal, but would require a LOT more work: we'd have to reorganize the existing project element hierarchy, move the help message from the analyses to the views, and make sure it works well with trace opening/closing (the list of views only becomes available when the trace is opened).

 Traces
   - kernel
     - Views
       - CPU Usage View
       - Control Flow View
       - Resource View
     - Analyses
       - LTTng-Analyses
     - Reports