From: John Keeping Date: Tue, 11 Feb 2014 15:14:52 GMT Subject: Re: Profiling support? Message-ID: <20140211151451.GA15032@serenity.lan> In-Reply-To: <878uthbtjg.fsf@fencepost.gnu.org> On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote: > Duy Nguyen writes: > > > On Tue, Feb 11, 2014 at 6:17 PM, David Kastrup 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