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

[Fabien Parent <parent f gmail com>]

Here a copy of the mail I sent on the nemiver ML, I forgot the add
this list on Cc.

On Tue, Apr 10, 2012 at 15:27, Fabien Parent <parent f gmail com> wrote:
> 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