Re: A new profiling tool for Nemiver (GSoC 2012 Application)

[Fabien Parent <parent f gmail com>]

Hello,

You can find my answers below

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

callgrind is clearly not the best and lighter profiling tool
out-there. I choose him for one main reason: it is the easiest entry
point to the valgrind framework. memcheck will be much harder to
implement, thus callgrind was a way to start with the valgrind
framework (development-wise).

>> 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?

GUI wise (the eclipse part), it would be a simple combobox containing
the name of every available perspectives at the right of the toolbar.
For the command line, i would see something like valgrind:
 - $ nemiver a.out: Start nemiver with the debugging perspective
 - $ nemiver --tool=debugger a.out: Same as above
 - $ nemiver --tool=profiler a.out:  Start nemiver with the profiling
perspective

>> 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?

I would see a tree (probably in a treeview) of all calls made where
the cost of call is added to its caller.
Example:
   - main (cost X+Y)
      > func1 (cost X)
         > subfunc1 (cost X)
      > func2 (cost Y)

On the side there would be a simple pie-chart showing the callee of
the selected function.

>> 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?

Yes