Re: Profiling support?

[John Keeping <john@keeping.me.uk>]

On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
> 
> > On Tue, Feb 11, 2014 at 6:17 PM, David Kastrup <dak@gnu.org> wrote:
> >>
> >> Looking in the Makefile, I just find support for coverage reports using
> >> gcov.  Whatever is there with "profile" in it seems to be for
> >> profile-based compilation rather than using gprof.
> >>
> >> Now since I've managed to push most of the runtime for basic git-blame
> >> operation out of blame.c proper, it becomes important to figure out
> >> where most of the remaining runtime (a sizable part of that being system
> >> time) is being spent.  Loop counts like that provided by gcov (or am I
> >> missing something here?) are not helpful for that, I think I rather need
> >> the kind of per-function breakdown that gprof provides.
> >>
> >> Is there a reason there are no prewired recipes or advice for using
> >> gprof on git?  Is there a way to get the work done, namely seeing the
> >> actual distribution of call times (rather than iterations) using gcov so
> >> that this is not necessary?
> >
> > Would perf help? No changes required, and almost no overhead, I think.
> 
> Not useful.  It would be probably nice for nailing down the performance
> gains when the work is finished so that future regressions will be
> noticeable.  It's reasonable easy to create a test case that will take
> hours with the current git-blame and would finish in seconds with the
> improved one.
> 
> But it's not useful at all for figuring out the hotspots within the
> git-blame binary.

I would have thought the annotation described at [1] is exactly what
you're looking for, isn't it?

Alternatively, I've had some success with callgrind and kCachegrind in
the past.

[1] https://perf.wiki.kernel.org/index.php/Tutorial#Source_level_analysis_with_perf_annotate