Christian Couder <christian.couder@xxxxxxxxx> 于2021年6月28日周一 上午5:53写道： > > > * Using Google's `gperftools`: > > [...] > > > 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. > Yes, maybe we need more precise time, and if it can locate the function in git will be better. > > * 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? > There is no clear conclusion yet. But it is likely to be xmemdupz, xstrdup. > Flame graphs (http://www.brendangregg.com/flamegraphs.html) might help > get a better idea of what happens. > Thanks, I will check if we can take use of it. > > 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! Thanks. -- ZheNing Hu
