Thomas Rast <> writes:

> David Kastrup <> writes:
>> Thomas Rast <> writes:
>>> David Kastrup <> 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
More majordomo info at

Reply via email to