David Kastrup <d...@gnu.org> writes:

> John Keeping <j...@keeping.me.uk> writes:
>> On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote:
>>> Duy Nguyen <pclo...@gmail.com> writes:
>>> > 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
> Misunderstanding on my part.  I thought this was about the "make perf"
> Makefile target.  I'll have to take a look at what the perf utility
> does.
> Thanks for the clarification.

Looks indeed like it could be useful.  In the currently working code
from me (last of the complex patch series), significant time is spent in
moving and allocating memory.  It might make sense not to continue
ignoring the patch I proposed to get rid of the absurd realloc series in
builtin/blame.c.  While it may not be responsible for all of avoidable
allocation churn, it's still large and untypical enough to mask further

David Kastrup
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

Reply via email to