Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

Linux Tools Project/Profiling/Unification


Linux Tools
Mailing ListForumsIRCmattermost
OpenHelp WantedBug Day
Browse Source

The actions for running the profiling tools we have now (Oprofile, Perf, Valgrind, Systemtap, GProf, etc.) are presenting themselves in the Profile As menu by name. This can be really confusing as some of them (Valgrind, Systemtap) are capable of more than one type of profiling making it hard to guess what type of profiling would one do if e.g "Profile with Valgrind" is chosen.

In order to simplify that we are looking to extend the profiling framework we have with simplified UI for running profiling per the type of profiling and not per tool. The types of profiling identified for now are:

  • memory - Valgrind, Systemtap?
  • function - Systemtap(Callgraph), Valgrind(Callgrind)
  • timing - Oprofile, Perf, Systemtap?, GProf
  • codecoverage - GCov

Linux Tools Profiling framework will contain plugins for every type of profiling (e.g. org.eclipse.linuxtools.profiling.memory), which will provide the following capabilities:

  • extension point for memory profilers to provide backends (e.g valgrind)
  • default launcher/menu for starting the profiling - The menu will be disabled/hidden if there is no backend installed. If there are backends installed the menu will start one based on priority from the extension. The launcher will also include launcher configuration page shared between the backends (e.g. paths, env. variables, etc.)
  • extension point to register backend specific configuration options dialog - This dialog should be another page in the launch dialog (if possible) or activateable from button/link.
  • unified presentation of the results (where possible) - Maybe similar tools like Oprofile and Perf can visualize the results in the same view and being responsibility of the backend to either feed the default view with data or use it's own if needed.

Relevant Bug(s) :


Launch Shortcut Implementation

The following work flow will be implemented :

We could create separate launch shortcuts for each type of profiling option (eg. Profile Memory, Profile function, etc.) . Each launch shortcut when launched through (Profile As -> Profile .. ) would check for the existence of a "provider" of that functionality. The provider would then be launched which would in turn, launch the appropriate delegate as before. As a result we'll need to add an additional attribute to all plugin specific launch configurations that tells us what type of profiling they provide.

Option 1

Use the launch configuration type, as the provider.

On a more detailed level, the implementation would be as follows :

  1. Create a launch shortcut for each profiling type (extending ProfileLaunchShortcut).
  2. Implement getLaunchConfigType() to return any (or a specific) ILaunchConfigurationType that has the attribute "modes" with a value that is associated with that particular type of profiling. As an example, for the Memory Profiling launch shortcut, getLaunchConfigType() might look for an ILaunchConfigurationType whose "modes" attribute contained "memory".
  3. Implement setDefaultProfilingAttributes(ILaunchConfigurationWorkingCopy) with any additional attributes, or leave it empty.
  4. For all profiling plugins that extend ProfilingLaunchShortcut, in the "org.eclipse.debug.core.launchConfigurationTypes" extention, make sure that all launchConfigurationType exention points specify a mode corresponding to the type of profiling. For example, if the plugin is for memory profiling, make sure that "memory" is specified. This could be a comma-separated list.

This is all that is needed to get a particular plugin to contribute their launch configuration to a particular profiling type. From this point we can always configure the rules for which launch configurations should take precedence.

Problems : This works well when one plugin contributes to one profiling type. The Valgrind plugin does not fit this model very well. We can easily have Valgrind contributing its default launch (Memcheck), but the various Valgrind plugins (Massif, Cachegrind, Hellgrind, etc.) are all handled by the same launch configuration (there's an attribute in the launch configuration that decides which of these plugins get used). If we would want Valgrind to contribute to multiple profiling types we would need to have a method where various plugins can provide their various ILaunchConfigurationTab. We could then use the setDefaults(ILaunchConfigurationWorkingCopy) of these classes to set the configuration correctly.

Option 2

Create a custom extention point and use the ILaunchShortcut of each plugin as the provider.

  1. Create a launch shortcut for each profiling type (extending ProfileLaunchShortcut).
  2. Create an extention point with 2 attributes (this would be part of the profiling framework):
    • An attribute called "type" that specifies a list of types of profiling (eg. memory,snapshot,timing)
    • An attribute that specifies a class that extends ProfilingLaunchShortcut
  3. Implement this extention point for all plugins that have a class extending ProfileLaunchShortcut. As an example, the Perf plugin could specify the extention point with a type of "snapshot", and provide their PerfLaunchShortcut as the class.

Note : Certain plugins (eg. Valgrind) would need to also provide some launch shortcuts for each tool they can provide (eg. Massif, Memcheck, Helgrind, Cachegrind) as for some, this is not currently done.

Launch Configuration Dialog Implementation

The following work flow will be implemented :

When a user enters the "Profile Configurations" dialog, there is an option to create a configuration for each profiling type (memory, snapshot, cpu, etc.). Each option has the general profiling tabs (Main, Arguments, Common, etc.), and an additional tab where a user can specify (from a drop-down list) the underlying tool they wish to use. Once selected, the specified tool's tabs/options would appear. For example, a user could create a Snapshot configuration, and select the Perf provider from the drop-down list. From there, the perf-specific tabs (Perf Events, Perf Options) would appear and this would eventually be passed off to Perf's launch delegate.

This mockup is a rough idea of how this dialog would be expected to look and function : dialog mockup

Problems : It may not be possible to add/remove tabs from a tab group in real-time from the launch configuration dialog. The only way to achieve similar functionality is through the usage of internal classes which isn't ideal at all.

Option 1

Instead of creating the tabs for the underlying tool at the same level as the other tabs (eg. Main, Arguments, Common, etc.), we can create the tool-specifc tabs inside the profiling type tab. This would avoid the issue of using internal classes. In addition it does not reduce the functionality in any way. In fact it would be more clear that the tabs under the profiling type are tool-specific.

For a more concrete example of what this entails, see dialog proposal

Back to the top