Re: Profiling support?

David Kastrup [off-list ref] writes:

John Keeping [off-list ref] writes:

quoted

On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote:

quoted

Duy Nguyen [off-list ref] writes:

quoted

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

Misunderstanding on my part.  I thought this was about the "make perf"
Makefile target.  I'll have to take a look at what the perf utility
does.

Thanks for the clarification.

Looks indeed like it could be useful.  In the currently working code
from me (last of the complex patch series), significant time is spent in
moving and allocating memory.  It might make sense not to continue
ignoring the patch I proposed to get rid of the absurd realloc series in
builtin/blame.c.  While it may not be responsible for all of avoidable
allocation churn, it's still large and untypical enough to mask further
culprits.

-- 
David Kastrup