A new profiling tool for Nemiver (GSoC 2012 Application)

[Dodji Seketeli <dodji seketeli org>]

Hello,

I am replying to a message initially posted by Fabien Parent to the
Nemiver mailing list[1] concerning his willingness to add profiling
tools to Nemiver.

This message is intended to kick off the usual discussion that arises
whenever someone makes a summer of code proposal.  I am thus sending
it to the GNOME SoC list as well as the Nemiver list.  Please keep
both lists as destinations of your follow-ups.

Below are my replies to the relevant parts of his proposal that you can
read at:

[1]: http://mail.gnome.org/archives/nemiver-list/2012-April/msg00000.html

> I think it’s time to take it to the next stage: implementing others
> developer dev/debug tools. That's why I am planning to implement in
> it several of valgrind tools: callgrind and memcheck at first.

Having Nemiver provide several tools have always been an idea that I
had in the back of my mind.  So I welcome your willingness to adding
profiling and debugging tools to the Nemiver workbench.

> Since this is a huge work

Indeed.  I think it is worth mentioning that the main goal of this SoC
will be to lay out the necessary building blocks for a *usable*
multi-tool setup for Nemiver.  I guess we will discuss what this takes
in details in this thread, if someone fills the need.

> my proposal is limited to the implementation of an UI for callgrind
> inside nemiver. And then when it will be mature enough I will move
> to the memcheck UI.

Interesting.  I remember that we had a discussion about adding a
profiling tool to Nemiver some time ago.  Using Callgrind seemed like
a good idea to me, but now that I think about it a bit more, I am
thinking that maybe using the Linux Perf tool might be more
"forward-looking".

The advantages of Perf compared to Callgrind seem to be the following
to me:

    1/ it (Perf) uses _much less_ memory and CPU than Callgrind.

    2/ it can be run on an embedded linux system, and Nemiver would
      analyze the result of the run "offline".  Note that the fact
      that Perf is in the mainline kernel makes it available on more
      architectures than Callgrind.

    3/ it allows system-wide profiling, giving the user a chance to
      drill down on the sub-system it thinks is sucking up CPU
      resources at will.

    4/ it easily lets the user know about the time spent in system
      calls and in the kernel.

In light of the points above, do you see a particular reason why we
should go for Callgrind instead of Perf?

Memcheck on the other hand seems like a killer contender (in its
category) to me.  Same goes for Helgrind, to find thread related
issues.


> I will begin the project by modifying the workbench to be able to
> change the current perspective (I will be doing it probably the same
> way eclipse does it).

I have no idea how Eclipse does it.  Would you please fancy explaining
this a little bit?

> The second step will be of writing the profiling engine which will be
> able at first of loading an executable under callgrind, process the
> result file and generate high-level structure to let the rest of the
> application manipulates the data without having to know about the
> internal of callgrind files.

Right.  We can dig into the details of this later.

> Once done I will write the perspective UI to start the executable and
> see the result of the profiling of the user binary. For this I’m
> currently planning to do a bonobo-like UI (based of charts).

Argh, please, don't mention bonobo.  This reminds me of too many
nightmares.

Would you care explaining what you mean by bonobo-like UI?

> The final step will be to be able to see the source code annotated,
> this will requires probably more work than I can handle in the short
> GSoC coding period. I will do be best to be able to get it to work
> quickly but I will probably have to continue it after the GSoC.

You mean hacking the GtkSourceView widget to let allow displaying
annotations in the margin, alongside breakpoints and such?

Thanks.
-- 
		Dodji