Hello, I have a problem here with git being slow in some situations. Using git 2.23.0 (from Debian) the effect is: ukl@xxxxxxxx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time git show v5.2 tag v5.2 ... real 0m12.727s user 0m0.300s sys 0m0.371s But to get the actual data isn't the problem: ukl@xxxxxxxx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time git show v5.2 | cat tag v5.2 ... real 0m0.764s user 0m0.014s sys 0m0.020s My expectation is that both commands should take approximately the same amount of time. This is 100% reproducible here. The backing filesystem could be quicker (don't know, this is xfs in an logical volume) but this applies to both calls, so this doesn't seem to be the biggest culprit at least. This is not a regression, I see similar problems since >2 years. (Didn't report before because I didn't know such an obvious reproducer.) Using perf I get in the first case: 7.99% git libz.so.1.2.11 [.] inflate 3.02% git libc-2.28.so [.] __memcmp_sse4_1 1.67% git [kernel.kallsyms] [k] __list_del_entry_valid 1.32% git [kernel.kallsyms] [k] unmap_page_range 1.25% git [kernel.kallsyms] [k] filemap_map_pages ... while with cat I get: 3.35% git [kernel.kallsyms] [k] __update_load_avg_cfs_rq 3.22% git [kernel.kallsyms] [k] update_blocked_averages 2.37% git [kernel.kallsyms] [k] __list_del_entry_valid 1.92% git [kernel.kallsyms] [k] hrtimer_interrupt 1.91% git [kernel.kallsyms] [k] __pagevec_lru_add_fn It doesn't seem to be related to stdio buffering or coloring as stdbuf -o0 git show --no-color v5.2 is slow, too. Any idea what could be the problem? Is there some info that I might report additionally to make this better understandable? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
