Re: [GSoC] Git Blog 6
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Jun 27, 2021, 21:52 UTC
- Message-ID
- <CAP8UFD0dDeL6crqqXPRd+564Z8n_EX3ctzRxKyGZFBp2SjbXEQ@mail.gmail.com>
- In-Reply-To
- <CAOLTT8TLhL3MNnkB7s1J4hAQmovaUPoeydn8kepzFOT_UL83_Q@mail.gmail.com>
On Sun, Jun 27, 2021 at 2:43 PM ZheNing Hu <adlternative@gmail.com> wrote:
> > My sixth week blog finished: > The web version is here: > https://adlternative.github.io/GSOC-Git-Blog-6/
Great!
[...]
Show 9 quoted lines
> Now the performance of `cat-file --batch` is almost half of the > previous performance of it, > because of the complex logic in `ref-filter`. So I am thinking, how > can I find the performance > bottleneck in `ref-filter` and optimize it? > > So I try to find and use performance testing tools to analyze the > time-consuming steps of > `git cat-file --batch`.
Yeah, that's the right thing to do at this point!
> * Using Google's `gperftools`:
[...]
Show 6 quoted lines
> Ignore `write`, `inflate` and `000055d9164cdc36`, the execution time of `memcmp` > and `memmove` is very large. > > However, whether it is `git cat-file` before or after re-using the > `ref-filter` logic, > the functions they call take up similar proportions of time.
Yeah, it's not clear what is causing performance issues from this. It may be that the issue is that with the ref-filter code more objects need to be fully read. I wonder if there is a way to count that.
Show 12 quoted lines
> * Using `perf`: > `perf top -p <git-pid>` > > ``` > 12.72% libc-2.33.so [.] __memmove_avx_unaligned_erms > 7.39% libz.so.1.2.11 [.] inflate > 5.56% libz.so.1.2.11 [.] 0x00000000000088ba > 5.27% libz.so.1.2.11 [.] adler32_z > 3.46% git [.] patch_delta > ``` > We can see that `memmove` is still the part that accounts for the > largest proportion of time.
Yeah. Do you think that the code is calling memmove directly or through another function? And anyway which part of the code is responsible for these calls?
Flame graphs (http://www.brendangregg.com/flamegraphs.html) might help get a better idea of what happens.
> We can already come to a conclusion: A lot of the time of `cat-file > --batch` is used for data copy, > this may be the focus of our later performance optimization.
Thanks!