On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote: > Duy Nguyen <pclo...@gmail.com> writes: > > > On Tue, Feb 11, 2014 at 6:17 PM, David Kastrup <d...@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 -- 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
