[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Progress report on git-blame
From: |
David Kastrup |
Subject: |
Re: Progress report on git-blame |
Date: |
Sat, 25 Jan 2014 11:12:24 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
David Kastrup <address@hidden> writes:
> martin rudalics <address@hidden> writes:
>
>>> Well, I finally did "git gc --aggressive" on my Emacs repository and
>>> tried again git-blame src/xdisp.c and the times got considerably _worse_
>>> than before the packing (though the repository went to about a quarter
>>> in size). So after my fixes the run time in real use cases is probably
>>> dominated by unpacking the various revisions, particularly with a
>>> well-compressed repository.
>>
>> Seems like the second law of thermodynamics still applies ...
>
> Yes, life is still easiest on the peanut galleries.
At any rate, I forgot to set the comparison function on the governing
priority queue, turning it into a FIFO. So the actual numbers on the
packed repository are not as disappointing as I first thought.
Here are the numbers, first the system version, then my own version:
address@hidden:/usr/local/tmp/emacs$ time git blame HEAD src/xdisp.c
>/tmp/blame1
real 3m17.437s
user 2m23.676s
sys 0m52.560s
address@hidden:/usr/local/tmp/emacs$ time ../git/git blame HEAD src/xdisp.c
>/tmp/blame2
real 1m24.628s
user 0m32.008s
sys 0m52.044s
address@hidden:/usr/local/tmp/emacs$ cmp /tmp/blame1 /tmp/blame2
address@hidden:/usr/local/tmp/emacs$
But it's obvious that significant further improvements will depend on
either or both
a) making git-blame respond to interactively determined requirements
(basically, reacting to expose events)
b) significantly decreasing the involved system time by employing a good
caching strategy
c) not letting the basic algorithm and the cached data progress
independently but try catering the workload order on what happens to be
in-memory at a given point of time.
c) is a very shady approach and would make debugging a nightmare.
At any rate, the user time already dropped by more than a factor of 4,
and I have not touched the inner work horse (the diff algorithm) at all,
just eliminated all the thrashing around it. Now the diff algorithm
itself is a separate library by a separate author, with widespread use.
It would be rather optimistic to assume that there are significantly
low-hanging fruit to be found there.
Shrug. I'll go see how I can reimplement the now defunct copy/move
detection not exercised without specific command line options in order
to get the current work into a shape where upstream can consider
accepting it.
--
David Kastrup
- Re: RFC - cleaning up /etc, (continued)
- Re: RFC - cleaning up /etc, Eric S. Raymond, 2014/01/11
- Re: RFC - cleaning up /etc, Lars Magne Ingebrigtsen, 2014/01/11
- Re: RFC - cleaning up /etc, Eric S. Raymond, 2014/01/11
- Re: RFC - cleaning up /etc, David Kastrup, 2014/01/11
- Re: RFC - cleaning up /etc, Eli Zaretskii, 2014/01/11
- Progress report on git-blame (was: RFC - cleaning up /etc), David Kastrup, 2014/01/24
- Re: Progress report on git-blame (was: RFC - cleaning up /etc), Eli Zaretskii, 2014/01/25
- Re: Progress report on git-blame, David Kastrup, 2014/01/25
- Re: Progress report on git-blame, martin rudalics, 2014/01/25
- Re: Progress report on git-blame, David Kastrup, 2014/01/25
- Re: Progress report on git-blame,
David Kastrup <=
- Re: Progress report on git-blame, Lars Ingebrigtsen, 2014/01/25
- Re: Progress report on git-blame, David Kastrup, 2014/01/25
- Re: Progress report on git-blame, Óscar Fuentes, 2014/01/25
- Re: Progress report on git-blame, David Kastrup, 2014/01/25
- Re: Progress report on git-blame, Eli Zaretskii, 2014/01/25
- Re: Progress report on git-blame, Óscar Fuentes, 2014/01/25
- Re: Progress report on git-blame, David Kastrup, 2014/01/25
- Re: Progress report on git-blame, Stefan Monnier, 2014/01/25
- Re: Progress report on git-blame, Aneesh Kumar K.V, 2014/01/26
- Re: Progress report on git-blame, Stefan Monnier, 2014/01/27