Re: Make the git codebase thread-safe

[David Kastrup <dak@gnu.org>]

Duy Nguyen <pclouds@gmail.com> writes:

> On Tue, Apr 2, 2019 at 5:30 PM David Kastrup <dak@gnu.org> wrote:
>>
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>> > On Tue, Apr 2, 2019 at 7:52 AM Matheus Tavares
>> > <matheus.bernardino@usp.br> wrote:
>> >> I downloaded chromium to give it a try and got (on a machine with i7 and
>> >> SSD, running Manjaro Linux):
>> >>
>> >> - 17s on blame for a file with long history[2]
>> >> - 2m on blame for a huge file[3]
>> >> - 15s on log for both [2] and [3]
>> >> - 1s for git status
>> >>
>> >> It seems quite a lot, especially with SSD, IMO.
>> >
>> > There have been a couple of optimizations that are probably still not
>> > enabled by default because they only benefit large repos.
>>
>> I've proposed a trivial change in 2014 that could have cut down typical
>> blame times significantly but nobody was interested in testing and
>> committing it, and it is conceivable that in limited-memory situations
>> it might warrant some accounting/mitigation for weird histories (not
>> that there isn't other code like that).
>
> I didn't really read the patch (I don't know much about blame.c to
> really contribute anything there). But a quick "git blame --show-stats
> unpack-trees.c" shows this
>
> Without the patch:
>
> num read blob: 767
> num get patch: 425
> num commits: 343
>
> With the patch:
>
> num read blob: 419
> num get patch: 425
> num commits: 343
>
> That's a nice reduction of blob reading. On a typical small file, the
> actual time saving might be not much. But it could really help when
> you blame a large file.
>
> Perhaps you could resubmit it again for inclusion? (at least a
> sign-off-by is missing then)

I don't expect it to go anywhere but will do.  Feel free to herd it.

-- 
David Kastrup