David Kastrup <d...@gnu.org> writes: > John Keeping <j...@keeping.me.uk> writes: > >> On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote: >>> Duy Nguyen <pclo...@gmail.com> writes: >>> >>> > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
