From: David Kastrup <dak@gnu.org>
To: Thomas Rast <tr@thomasrast.ch>
Cc: git@vger.kernel.org
Subject: Re: Profiling support?
Date: Sun, 16 Feb 2014 18:05:42 +0100 [thread overview]
Message-ID: <87lhxbvvh5.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87mwhr2e1w.fsf@thomasrast.ch> (Thomas Rast's message of "Sun, 16 Feb 2014 17:54:51 +0100")
Thomas Rast <tr@thomasrast.ch> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Thomas Rast <tr@thomasrast.ch> writes:
>>
>>> David Kastrup <dak@gnu.org> 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
prev parent reply other threads:[~2014-02-16 17:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-11 11:17 Profiling support? David Kastrup
2014-02-11 13:18 ` Duy Nguyen
2014-02-11 14:41 ` David Kastrup
2014-02-11 15:14 ` John Keeping
2014-02-11 15:19 ` David Kastrup
2014-02-11 20:53 ` David Kastrup
2014-02-16 15:44 ` Thomas Rast
2014-02-16 15:59 ` David Kastrup
2014-02-16 16:54 ` Thomas Rast
2014-02-16 17:05 ` David Kastrup [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lhxbvvh5.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=tr@thomasrast.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.