Re: [Valgrind-developers] suggestion for cachegrind/callgrind: finer-grained profiling

[Josef W. <Jos...@gm...>]

Hi Ilya,

On Monday 19 September 2011, ilya shlyakhter wrote:
> how hard would it be to implement the following extension to
> cachegrind/callgrind:
> ...

this list (which I do not understand completely) suggests that
you have some concrete use case in mind. What do you want to
accomplish in the end?

> right now, when reporting the cost of a function, the cost of all
> invocations is aggregated together.
> (callgrind separates the invocations by caller, but that's as
> fine-grained as it goes).

Hmm.. you can also dump counters to a file anytime you want,
e.g. with "--dump-after=<func>". You then can post-process
the files, and do your own statistics on it.
For how to parse the files in PERL, see "callgrind_annotate".

If writing millions of files is to expensive, it probably is
easier to think about a way to pass measurements to a script
in a more light-weight way (e.g. via pipes). You should
be able to implement your suggestions in your own script then.

> the proposed extension would do the following:
>  - for each function (or for requested functions), for a chosen
> statistic (Ir, DLmr, etc), produce a _histogram_ of invocation costs.
>    in each bin, keep the # of invocations and their total cost.

> an additional extension would let the user print their own debug
> information for representative
> invocations falling into a given bin.  this would work only for
> completely deterministic user programs.
>   - there would be a valgrind client request, VALGRIND_SHOULD_PRINT,
> which the user would
>     add to their function to tell them whether to print debug
> information for this invocation:
> 
>  void myFunc( ComplexStructure *arg ) {
>     if( VALGRIND_SHOULD_PRINT )
>          arg->print();
>     ...
>  }
>   - there would be an option to cachegrind/callgrind to record and
> save in an output file, for a given function and
>   a given range of costs, the "invocation ids" of some small number
> of invocations of that function in that cost range.
>   "invocation id" of a function is simply the order number of its
> invocation (e.g. the 134701st invocation of this function).
> 
>   - there would be another option to cachegrind/callgrind to read the
> file recorded above and to have VALGRIND_SHOULD_PRINT return 1
>   for the recorded invocations, and 0 for all others.

I don't understand the benefit. How would you use that feature?

> this would allow finer-grained profiling than is currently possible.
> how hard would this be to add?

If you come up with a patch, you still need to prove that it is worth
merging and maintaining. It seems easier to me to try to come up
with a general solution which allows users to implement their own
post-processing/statistics, as mentioned above.

E.g. for adding histograms, you not only need to change cachegrind/callgrind,
but also extend the format and parsers, such as {cg,callgrind}_annotate,
and the KCachegrind GUI.

That said, it would be cool to have histograms.

Josef

> 
> thanks,
> 
> ilya
> 
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the 
> BlackBerry&reg; mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry&reg; DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1 
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>