Thomas Rast <tr@xxxxxxxxxxxxx> writes: > David Kastrup <dak@xxxxxxx> writes: > >> Thomas Rast <tr@xxxxxxxxxxxxx> writes: >> >>> David Kastrup <dak@xxxxxxx> writes: >>> >>>> 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. >>> [...] >>>> 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? >>> >>> No reason I'm aware of, other than that nobody ever wrote it. >> >> A solid testing/benchmarking framework would quite seem like a useful >> GSoC project as it would make it easy for casual programmers to dip >> their feet into their personal bottlenecks, and it would make it much >> easier to find worthwhile hotspots for future projects taking the >> challenge of speeding up core and/or specific operations. >> >>> Note that I wouldn't exactly be surprised if the gcov targets had >>> bitrotted without anyone noticing. I haven't heard of any heavy users. >>> I originally wrote them to do some basic test coverage analysis, but >>> that's about it. >> >> I've managed to make use of the outer sandwich layers: the prepare and >> the evaluate stuff. I ran my own tests for benchmarking though. > > Umm, are we even discussing the same thing here? Maybe not. > Are you saying you ran profiling-instrumented code under the t/perf/ > support code? No. I used the toplevel Makefile targets coverage-clean, coverage-compile and, after running my own problematic test cases, coverage-report. I did not use the coverage-test target, nor did I venture into t/perf/ in any other way. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html