[cdt-dev] Local C/C++ Application Launch and Linux Tools Profiling

[Jeff Johnston <jjohnstn@xxxxxxxxxx>]

I'd like to start a conversation with the CDT debug/launch maintainers 
regarding profiling.

At present, Linux Tools creates a set of Launch short-cuts that support 
various profiling tools.  As such, they all appear under the Profile 
As... menu per the Launch short-cut framework.  For example, there is a 
Profile with Valgrind (which uses memcheck) and a Profile with OProfile.

We are currently under way unifying our own profiling framework to group 
tools into categories such as Profile Memory, Profile Timing, and 
Profile Coverage whereby the user would get a default tool selected for 
them and they don't need to have detailed knowledge regarding the 
various tools.  The user still has the ability to change which tool is 
the default for any category (e.g. they could select using Memory Usage 
via Valgrind Massif instead of Memory Checking via Valgrind Memcheck) 
and can set tool options in the case where they are experienced users.

In truth, the short-cuts we are creating are really for a Local C/C++ 
Application and it doesn't make sense to add them all to the Profile 
as.. menu.  The menu wording sequence also doesn't make sense: e.g. 
Profile as..->Profile with Valgrind.  We should be instead providing a 
single short-cut: Profile as..->Local C/C++ Application to be consistent 
with the current CDT Run as.. and Debug as.. short-cuts and so that the 
menu selection makes sense.

It would be beneficial to allow the user to set common parameters among 
Run as.., Debug as.., and Profile as...

I would like to propose for Kepler that the CDT Launch short-cut: 
"org.eclipse.cdt.debug.ui.localCShortcut" add a profile mode.

To handle the low-level profiling support, I propose a new CDT extension 
that would specify a CDT Profile proxy provider.  The id for the profile 
provider could be constructed based on an existing CDT id (e.g. the 
launch type id) so that it would be relatively easy for CDT to find the 
appropriate extension to use.

The Local Application profiling support could proxy off a few items such 
as additional tabs and the actual delegate to use.  In the case of Linux 
Tools, there would be a single tab which would allow setting of the 
profiling category and the appropriate tool.  Third-party tools can be 
added easily to the Linux Tool profiling framework in the future.  By 
default, profiling would use Perf (if the plug-in is installed) which 
provides timing information and does not require any set-up or root 
access to use.

Ideally, I would like to be able to suppress gdb references in the tabs 
when the mode is profile since gdb won't be used, but I would not want 
to disrupt current Run and Debug behaviour.

As mentioned, the CDT Local C/C++ application profiling delegate would 
punt to the delegate from the extension to perform the execution and 
profiling via whatever tools are specified in the tabs and preferences.

Using such an extension, the CDT would not have any requirements on 
Linux Tools.

In the case where the profiling provider is not found, the code could 
default to add a default Profiling tab which simply notes there are no 
profiling providers installed and the regular Run delegate would be used.

Thoughts?  Issues?

-- Jeff J.