Thread: [Kcachegrind-callgrind] customizing kcachegrind for limited GNU make profile data

Status: Beta

Brought to you by: weidendo

kcachegrind-callgrind

[Kcachegrind-callgrind] customizing kcachegrind for limited GNU make profile data

From: Rocky B. <ro...@gn...> - 2015-05-31 14:19:46

I've recently discovered kcachegrind and it is awesome. I am using it to
show profiling and callgraph data for GNU make runs in a fork of GNU make
that adds profiling <http://bashdb.sourceforge.net/remake/>

Of course, in the context of GNU Make profile data, there is an analogy
going on (e.g. stack of target dependencies being made is approximately a
call stack). Not all of the features you would find in profiling a machine
executable are relevant. Specifically, there are no machine instructions so
the "Machine Code" tab is useless. And "grouping" by ELF object or Class is
also not meaningful.

Is there a way to tell kcachegrind to hide or disable such options?

Thanks.

Re: [Kcachegrind-callgrind] customizing kcachegrind for limited GNU make profile data

From: Josef W. <Jos...@gm...> - 2015-06-08 14:15:23

Hi Rocky,

of course it would be nice to make kcachegrind (or the pure Qt version
qcachegrind)
usable for other visualization needs, as long as this makes some sense.

What do you actually see missing?
The current format already makes instruction addresses optional, but a
more explicit
way to toggle visualizations on/off may be useful.

If you have a patch available, just send it.

Best,
Josef

Am 31.05.2015 um 16:19 schrieb Rocky Bernstein:
> I've recently discovered kcachegrind and it is awesome. I am using it to
> show profiling and callgraph data for GNU make runs in afork of GNU make
> that adds profiling <http://bashdb.sourceforge.net/remake/>
> 
> Of course, in the context of GNU Make profile data, there is an analogy
> going on (e.g. stack of target dependencies being made is approximately
> a call stack). Not all of the features you would find in profiling a
> machine executable are relevant. Specifically, there are no machine
> instructions so the "Machine Code" tab is useless. And "grouping" by ELF
> object or Class is also not meaningful.
> 
> Is there a way to tell kcachegrind to hide or disable such options? 
> 
> Thanks.
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Kcachegrind-callgrind mailing list
> Kca...@li...
> https://lists.sourceforge.net/lists/listinfo/kcachegrind-callgrind
>

Re: [Kcachegrind-callgrind] customizing kcachegrind for limited GNU make profile data

From: Rocky B. <ro...@gn...> - 2015-06-08 15:32:25

If we agree on an acceptable way to accomplish the simplification, perhaps
I'll work something up.

The big picture is that while kcachegrind has a lot of features and many of
them are cool, there are number of situations where buttons aren't
applicable. In those cases, I think it would be great to grey out or hide
the buttons. My take is hide the buttons. And my take is that doing this
automatically is preferable to having a user deselect things that aren't
applicable.

So is it feasible to remove grouping by ELF object or class in the dropdown
and the "Machine Code" tab if there isn't any machine code as determined by
the specific data?

On Mon, Jun 8, 2015 at 10:15 AM, Josef Weidendorfer <
Jos...@gm...> wrote:

> Hi Rocky,
>
> of course it would be nice to make kcachegrind (or the pure Qt version
> qcachegrind)
> usable for other visualization needs, as long as this makes some sense.
>
> What do you actually see missing?
> The current format already makes instruction addresses optional, but a
> more explicit
> way to toggle visualizations on/off may be useful.
>
> If you have a patch available, just send it.
>
> Best,
> Josef
>
> Am 31.05.2015 um 16:19 schrieb Rocky Bernstein:
> > I've recently discovered kcachegrind and it is awesome. I am using it to
> > show profiling and callgraph data for GNU make runs in afork of GNU make
> > that adds profiling <http://bashdb.sourceforge.net/remake/>
> >
> > Of course, in the context of GNU Make profile data, there is an analogy
> > going on (e.g. stack of target dependencies being made is approximately
> > a call stack). Not all of the features you would find in profiling a
> > machine executable are relevant. Specifically, there are no machine
> > instructions so the "Machine Code" tab is useless. And "grouping" by ELF
> > object or Class is also not meaningful.
> >
> > Is there a way to tell kcachegrind to hide or disable such options?
> >
> > Thanks.
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > Kcachegrind-callgrind mailing list
> > Kca...@li...
> > https://lists.sourceforge.net/lists/listinfo/kcachegrind-callgrind
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Kcachegrind-callgrind mailing list
> Kca...@li...
> https://lists.sourceforge.net/lists/listinfo/kcachegrind-callgrind
>

Re: [Kcachegrind-callgrind] customizing kcachegrind for limited GNU make profile data

From: Josef W. <Jos...@gm...> - 2015-06-08 18:05:21

Am 08.06.2015 um 17:32 schrieb Rocky Bernstein:
> hide the buttons. My take is hide the buttons.

Sounds reasonable.

> And my take is that doing this automatically is preferable
> to having a user deselect things that aren't applicable.

Sure, some automatism without user involvment is good.

> So is it feasible to remove grouping by ELF object or class in the
> dropdown and the "Machine Code" tab if there isn't any machine code as
> determined by the specific data? 

Currently KCachegrind has the "machine code" tab visible even
if there is no data to show, as I want to "teach" users by
showing a hint for how to enable measurement at machine code level
(knowing that people do not read manuals).

Wouldn't it be enough to extend the profile format with a header
field to suppress UI elements/features?

Josef

> On Mon, Jun 8, 2015 at 10:15 AM, Josef Weidendorfer
> <Jos...@gm... <mailto:Jos...@gm...>> wrote:
> 
>     Hi Rocky,
> 
>     of course it would be nice to make kcachegrind (or the pure Qt version
>     qcachegrind)
>     usable for other visualization needs, as long as this makes some sense.
> 
>     What do you actually see missing?
>     The current format already makes instruction addresses optional, but a
>     more explicit
>     way to toggle visualizations on/off may be useful.
> 
>     If you have a patch available, just send it.
> 
>     Best,
>     Josef
> 
>     Am 31.05.2015 um 16:19 schrieb Rocky Bernstein:
>     > I've recently discovered kcachegrind and it is awesome. I am using it to
>     > show profiling and callgraph data for GNU make runs in afork of GNU make
>     > that adds profiling <http://bashdb.sourceforge.net/remake/>
>     >
>     > Of course, in the context of GNU Make profile data, there is an analogy
>     > going on (e.g. stack of target dependencies being made is approximately
>     > a call stack). Not all of the features you would find in profiling a
>     > machine executable are relevant. Specifically, there are no machine
>     > instructions so the "Machine Code" tab is useless. And "grouping" by ELF
>     > object or Class is also not meaningful.
>     >
>     > Is there a way to tell kcachegrind to hide or disable such options?
>     >
>     > Thanks.
>     >
>     >
>     > ------------------------------------------------------------------------------
>     >
>     >
>     >
>     > _______________________________________________
>     > Kcachegrind-callgrind mailing list
>     > Kca...@li...
>     <mailto:Kca...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/kcachegrind-callgrind
>     >
> 
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Kcachegrind-callgrind mailing list
>     Kca...@li...
>     <mailto:Kca...@li...>
>     https://lists.sourceforge.net/lists/listinfo/kcachegrind-callgrind
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Kcachegrind-callgrind mailing list
> Kca...@li...
> https://lists.sourceforge.net/lists/listinfo/kcachegrind-callgrind
>

Re: [Kcachegrind-callgrind] customizing kcachegrind for limited GNU make profile data

From: Rocky B. <ro...@gn...> - 2015-06-08 18:21:44

On Mon, Jun 8, 2015 at 2:05 PM, Josef Weidendorfer <
Jos...@gm...> wrote:

> Am 08.06.2015 um 17:32 schrieb Rocky Bernstein:
> > hide the buttons. My take is hide the buttons.
>
> Sounds reasonable.
>

Specifically I'm thinking of hiding the "function cycle" grouping when
there aren't any.  If there are no ELF objects, (I guess no "ob=" in the
callgrind.out file), then a dummy is created to put everything under. But
another possibility is just leaving off that choice of grouping by ELF
objects. Same thing goes with "Class". For a non-OO C program it looks like
a "global" class is created. And for GNU Makefiles, "Class" doesn't make
sense. So perhaps would be just to simplify the grouping and leave that off
as well.


> > And my take is that doing this automatically is preferable
> > to having a user deselect things that aren't applicable.
>
> Sure, some automatism without user involvment is good.
>
> > So is it feasible to remove grouping by ELF object or class in the
> > dropdown and the "Machine Code" tab if there isn't any machine code as
> > determined by the specific data?
>
> Currently KCachegrind has the "machine code" tab visible even
> if there is no data to show, as I want to "teach" users by
> showing a hint for how to enable measurement at machine code level
> (knowing that people do not read manuals).
>

Fair enough. Here is another possibility.  Note that when only one
callgrind.out file is around "Parts" is greyed out. Would it be okay to
also grey out "Machine Code" when there is none but  have the message under
assembly instruction be given as a tool tip when it is greyed out? And
there could be tooltips under the other buttons like "Parts" as well.


> Wouldn't it be enough to extend the profile format with a header
> field to suppress UI elements/features?
>

That would work too, although it would lead to extending the protocol. Let
me know what you would prefer.


>
> Josef
>
> > On Mon, Jun 8, 2015 at 10:15 AM, Josef Weidendorfer
> > <Jos...@gm... <mailto:Jos...@gm...>> wrote:
> >
> >     Hi Rocky,
> >
> >     of course it would be nice to make kcachegrind (or the pure Qt
> version
> >     qcachegrind)
> >     usable for other visualization needs, as long as this makes some
> sense.
> >
> >     What do you actually see missing?
> >     The current format already makes instruction addresses optional, but
> a
> >     more explicit
> >     way to toggle visualizations on/off may be useful.
> >
> >     If you have a patch available, just send it.
> >
> >     Best,
> >     Josef
> >
> >     Am 31.05.2015 um 16:19 schrieb Rocky Bernstein:
> >     > I've recently discovered kcachegrind and it is awesome. I am using
> it to
> >     > show profiling and callgraph data for GNU make runs in afork of
> GNU make
> >     > that adds profiling <http://bashdb.sourceforge.net/remake/>
> >     >
> >     > Of course, in the context of GNU Make profile data, there is an
> analogy
> >     > going on (e.g. stack of target dependencies being made is
> approximately
> >     > a call stack). Not all of the features you would find in profiling
> a
> >     > machine executable are relevant. Specifically, there are no machine
> >     > instructions so the "Machine Code" tab is useless. And "grouping"
> by ELF
> >     > object or Class is also not meaningful.
> >     >
> >     > Is there a way to tell kcachegrind to hide or disable such options?
> >     >
> >     > Thanks.
> >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Kcachegrind-callgrind mailing list
> >     > Kca...@li...
> >     <mailto:Kca...@li...>
> >     > https://lists.sourceforge.net/lists/listinfo/kcachegrind-callgrind
> >     >
> >
> >
>  ------------------------------------------------------------------------------
> >     _______________________________________________
> >     Kcachegrind-callgrind mailing list
> >     Kca...@li...
> >     <mailto:Kca...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/kcachegrind-callgrind
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > Kcachegrind-callgrind mailing list
> > Kca...@li...
> > https://lists.sourceforge.net/lists/listinfo/kcachegrind-callgrind
> >
>