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

[Rocky B. <ro...@gn...>]

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