Difference between revisions of "Linux Tools Project/Profiling/Unification"

Revision as of 12:32, 14 June 2012

{{#eclipseproject:technology.linux-distros}}

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 priotiry 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.

Implementation

Option 1

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. When we say "provider" it's likely that we'd be looking for a launch configuration that will have some attribute indicating it supports the appropriate type of profiling. For example, "Profile Memory" might return the launch configuration for Valgrind Massif. This configuration 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.

On a more detailed level, org.eclipse.linuxtools.profiling.launch.ProfilingLaunchShortcut:findLaunchConfiguration(..) is what returns an ILaunchConfiguration for all our profiling tools. This method just looks for any launch configuration whose type has a specific ID. For example, when the PerfLaunchShortcut is called, findLaunchConfiguration will return a launch configuration whose type has the ID : "org.eclipse.linuxtools.perf.launch.profile". This ID is defined in the Perf plugin's extention points, under LaunchConfigTypes. This is how our plugins provide their own launch configurations.

In the case of our proposed profiling menus, we could make a method similar to findLaunchConfiguration, but it would return a launch configuration whose type has an attribute that indicates it supports a particular type of profiling.