Re: Git in Outreachy?

[Matheus Tavares Bernardino <matheus.bernardino@usp.br>]

On Sun, Sep 5, 2021 at 5:59 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> Jeff King <peff@peff.net> 于2021年9月4日周六 下午8:50写道：
> >
> > On Sat, Sep 04, 2021 at 03:40:41PM +0800, ZheNing Hu wrote:
> >
> > > This may be a place to promote my patches: See [1][2][3].
> > > It can provide some extra atoms for git cat-file --batch | --batch-check,
> > > like %(tree), %(author), %(tagger) etc. Although some performance
> > > optimizations have been made, It still has small performance gap.
> > >
> > > If the community still expects git cat-file --batch to reuse the logic
> > > of ref-filter,
> > > I expect it to get the attention of reviewers.
> > >
> > > The solutions I can think of to further optimize performance are:
> > > 1. Delay the evaluation of some ref-filter intermediate data.
> > > 2. Let ref-filter code reentrant and can be called in multi-threaded  to take
> > > advantage of multi-core.
> >
> > I don't think trying to thread it will help much. For expensive formats,
> > where we have to actually open and parse objects, in theory we could do
> > that in parallel. But most of our time there is spent in zlib getting
> > the object data, and that all needs to be done under a big lock.
>
> This big lock is "obj_read_lock()", right?

The object reading code actually releases this lock before doing zlib
decompression (and acquires it right after), to allow better
multi-threaded performance.

However, it is unfortunately not so simple to call object reading
routines in multi-threaded code, even with this lock. The lock mainly
protects `oid_object_info_extended()` and its wrappers. Some global
resources used by these functions are also accessed outside of them,
which could lead to race conditions in threaded code.

That's why `builtin/grep.c` and `grep.c` have some explicit calls to
`obj_read_lock()` outside `object-file.c` and `packfile.c`. (And it
can be quite tricky to identity these cases.)