{"thread":{"id":"51755","subject":"git slow unless piped to cat","startedAt":"2019-08-27T08:16:03Z","lastAt":"2019-08-28T10:24:37Z","messageCount":13,"participants":["Uwe Kleine-König","SZEDER Gábor","Philipp Zabel","Michal Suchánek","Jeff King","Bryan Turner"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"381322","messageId":"20190827081559.mt5wjpdvqzn62dib@pengutronix.de","threadId":"51755","inReplyTo":null,"subject":"git slow unless piped to cat","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2019-08-27T08:15:59Z","receivedAt":"2019-08-27T08:16:03Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nI have a problem here with git being slow in some situations.\nUsing git 2.23.0 (from Debian) the effect is:\n\nukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2\ntag v5.2\n...\n\nreal\t0m12.727s\nuser\t0m0.300s\nsys\t0m0.371s\n\nBut to get the actual data isn't the problem:\n\nukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2 | cat\ntag v5.2\n...\n\nreal\t0m0.764s\nuser\t0m0.014s\nsys\t0m0.020s\n\nMy expectation is that both commands should take approximately the same\namount of time. This is 100% reproducible here.\n\nThe backing filesystem could be quicker (don't know, this is xfs in an\nlogical volume) but this applies to both calls, so this doesn't seem to\nbe the biggest culprit at least.\n\nThis is not a regression, I see similar problems since >2 years. (Didn't\nreport before because I didn't know such an obvious reproducer.)\n\nUsing perf I get in the first case:\n\n 7.99% git libz.so.1.2.11 [.] inflate\n 3.02% git libc-2.28.so [.] __memcmp_sse4_1\n 1.67% git [kernel.kallsyms] [k] __list_del_entry_valid\n 1.32% git [kernel.kallsyms] [k] unmap_page_range\n 1.25% git [kernel.kallsyms] [k] filemap_map_pages\n ...\n\nwhile with cat I get:\n\n 3.35% git [kernel.kallsyms] [k] __update_load_avg_cfs_rq\n 3.22% git [kernel.kallsyms] [k] update_blocked_averages\n 2.37% git [kernel.kallsyms] [k] __list_del_entry_valid\n 1.92% git [kernel.kallsyms] [k] hrtimer_interrupt\n 1.91% git [kernel.kallsyms] [k] __pagevec_lru_add_fn\n\nIt doesn't seem to be related to stdio buffering or coloring as\n\n\tstdbuf -o0 git show --no-color v5.2\n\nis slow, too.\n\nAny idea what could be the problem? Is there some info that I might\nreport additionally to make this better understandable?\n\nBest regards\nUwe\n\n-- \nPengutronix e.K. | Uwe Kleine-König |\nIndustrial Linux Solutions | http://www.pengutronix.de/ |\n"},{"id":"381323","messageId":"20190827084111.GU20404@szeder.dev","threadId":"51755","inReplyTo":"20190827081559.mt5wjpdvqzn62dib@pengutronix.de","subject":"Re: git slow unless piped to cat","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-27T08:41:11Z","receivedAt":"2019-08-27T08:41:17Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:\n> I have a problem here with git being slow in some situations.\n> Using git 2.23.0 (from Debian) the effect is:\n> \n> ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2\n> tag v5.2\n> ...\n> \n> real\t0m12.727s\n> user\t0m0.300s\n> sys\t0m0.371s\n> \n> But to get the actual data isn't the problem:\n> \n> ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2 | cat\n> tag v5.2\n> ...\n> \n> real\t0m0.764s\n> user\t0m0.014s\n> sys\t0m0.020s\n> \n\nHow does 'git --no-pager show v5.2' perform? If it's as fast as the\ncase piping the output to cat, then look into what pager and pager\noptions you use.\n\n"},{"id":"381325","messageId":"20190827085637.g6cpnuofpteyfqfz@pengutronix.de","threadId":"51755","inReplyTo":"20190827084111.GU20404@szeder.dev","subject":"Re: git slow unless piped to cat","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2019-08-27T08:56:37Z","receivedAt":"2019-08-27T08:56:40Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"On Tue, Aug 27, 2019 at 10:41:11AM +0200, SZEDER Gábor wrote:\n> On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:\n> > I have a problem here with git being slow in some situations.\n> > Using git 2.23.0 (from Debian) the effect is:\n> > \n> > ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2\n> > tag v5.2\n> > ...\n> > \n> > real\t0m12.727s\n> > user\t0m0.300s\n> > sys\t0m0.371s\n> > \n> > But to get the actual data isn't the problem:\n> > \n> > ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2 | cat\n> > tag v5.2\n> > ...\n> > \n> > real\t0m0.764s\n> > user\t0m0.014s\n> > sys\t0m0.020s\n> > \n> \n> How does 'git --no-pager show v5.2' perform? If it's as fast as the\n> case piping the output to cat, then look into what pager and pager\n> options you use.\n\n\tukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git --no-pager show v5.2\n\ttag v5.2\n\t...\n\n\treal\t0m13.225s\n\tuser\t0m0.355s\n\tsys\t0m0.336s\n\nSo this doesn't seem to be the problem. Also the local configuration\ncan be ruled out:\n\n\tukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color v5.2\n\ttag v5.2\n\t...\n\n\treal\t0m13.587s\n\tuser\t0m0.335s\n\tsys\t0m0.336s\n\nThanks\nUwe\n\n-- \nPengutronix e.K. | Uwe Kleine-König |\nIndustrial Linux Solutions | http://www.pengutronix.de/ |\n"},{"id":"381328","messageId":"1566897126.4102.5.camel@pengutronix.de","threadId":"51755","inReplyTo":"20190827085637.g6cpnuofpteyfqfz@pengutronix.de","subject":"Re: git slow unless piped to cat","fromName":"Philipp Zabel","fromEmail":"p.zabel@pengutronix.de","sentAt":"2019-08-27T09:12:06Z","receivedAt":"2019-08-27T09:12:10Z","isPatch":false,"sender":{"key":"p.zabel@pengutronix.de","avatar":null},"body":"On Tue, 2019-08-27 at 10:56 +0200, Uwe Kleine-König wrote:\n> On Tue, Aug 27, 2019 at 10:41:11AM +0200, SZEDER Gábor wrote:\n> > On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:\n> > > I have a problem here with git being slow in some situations.\n> > > Using git 2.23.0 (from Debian) the effect is:\n> > > \n> > > ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2\n> > > tag v5.2\n> > > ...\n> > > \n> > > real\t0m12.727s\n> > > user\t0m0.300s\n> > > sys\t0m0.371s\n> > > \n> > > But to get the actual data isn't the problem:\n> > > \n> > > ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2 | cat\n> > > tag v5.2\n> > > ...\n> > > \n> > > real\t0m0.764s\n> > > user\t0m0.014s\n> > > sys\t0m0.020s\n> > > \n> > \n> > How does 'git --no-pager show v5.2' perform? If it's as fast as the\n> > case piping the output to cat, then look into what pager and pager\n> > options you use.\n> \n> \tukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git --no-pager show v5.2\n> \ttag v5.2\n> \t...\n> \n> \treal\t0m13.225s\n> \tuser\t0m0.355s\n> \tsys\t0m0.336s\n> \n> So this doesn't seem to be the problem. Also the local configuration\n> can be ruled out:\n> \n> \tukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color v5.2\n> \ttag v5.2\n> \t...\n> \n> \treal\t0m13.587s\n> \tuser\t0m0.335s\n> \tsys\t0m0.336s\n> \n> Thanks\n> Uwe\n\nHave you checked strace output? I see a directory walk through .git/refs\nand .git/packed-refs if the output is not redirected.\n\nregards\nPhilipp\n"},{"id":"381331","messageId":"20190827094407.GV20404@szeder.dev","threadId":"51755","inReplyTo":"1566897126.4102.5.camel@pengutronix.de","subject":"Re: git slow unless piped to cat","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-27T09:44:07Z","receivedAt":"2019-08-27T09:44:14Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Aug 27, 2019 at 11:12:06AM +0200, Philipp Zabel wrote:\n> On Tue, 2019-08-27 at 10:56 +0200, Uwe Kleine-König wrote:\n> > On Tue, Aug 27, 2019 at 10:41:11AM +0200, SZEDER Gábor wrote:\n> > > On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:\n> > > > I have a problem here with git being slow in some situations.\n> > > > Using git 2.23.0 (from Debian) the effect is:\n> > > > \n> > > > ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2\n> > > > tag v5.2\n> > > > ...\n> > > > \n> > > > real\t0m12.727s\n> > > > user\t0m0.300s\n> > > > sys\t0m0.371s\n> > > > \n> > > > But to get the actual data isn't the problem:\n> > > > \n> > > > ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2 | cat\n> > > > tag v5.2\n> > > > ...\n> > > > \n> > > > real\t0m0.764s\n> > > > user\t0m0.014s\n> > > > sys\t0m0.020s\n> > > > \n> > > \n> > > How does 'git --no-pager show v5.2' perform? If it's as fast as the\n> > > case piping the output to cat, then look into what pager and pager\n> > > options you use.\n> > \n> > \tukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git --no-pager show v5.2\n> > \ttag v5.2\n> > \t...\n> > \n> > \treal\t0m13.225s\n> > \tuser\t0m0.355s\n> > \tsys\t0m0.336s\n> > \n> > So this doesn't seem to be the problem. Also the local configuration\n> > can be ruled out:\n> > \n> > \tukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color v5.2\n> > \ttag v5.2\n> > \t...\n> > \n> > \treal\t0m13.587s\n> > \tuser\t0m0.335s\n> > \tsys\t0m0.336s\n> > \n> > Thanks\n> > Uwe\n> \n> Have you checked strace output? I see a directory walk through .git/refs\n> and .git/packed-refs if the output is not redirected.\n\nThat's a good point, 'git show/log' show decorations (refs pointing to\nany commits shown) when the output is a terminal:\n\n $ git show v5.2\n [...]\n commit 0ecfebd2b52404ae0c54a878c872bb93363ada36 (HEAD -> master, tag: v5.2)\n [...]\n $ git show v5.2 |cat\n [...]\n commit 0ecfebd2b52404ae0c54a878c872bb93363ada36\n [...]\n\nAnd indeed, if you have a lot of refs and cold cache, then that might\naccount for a couple of seconds difference. So, how does 'git show\n--no-decorate v5.2' perform, and if it performs well, then how many\nrefs do you have ('git for-each-ref |wc -l')?\n\n"},{"id":"381334","messageId":"20190827100427.u3a5uvmylm5vddn2@pengutronix.de","threadId":"51755","inReplyTo":"20190827094407.GV20404@szeder.dev","subject":"Re: git slow unless piped to cat","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2019-08-27T10:04:27Z","receivedAt":"2019-08-27T10:04:30Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"On Tue, Aug 27, 2019 at 11:44:07AM +0200, SZEDER Gábor wrote:\n> On Tue, Aug 27, 2019 at 11:12:06AM +0200, Philipp Zabel wrote:\n> > On Tue, 2019-08-27 at 10:56 +0200, Uwe Kleine-König wrote:\n> > > On Tue, Aug 27, 2019 at 10:41:11AM +0200, SZEDER Gábor wrote:\n> > > > On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:\n> > > > > I have a problem here with git being slow in some situations.\n> > > > > Using git 2.23.0 (from Debian) the effect is:\n> > > > > \n> > > > > ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2\n> > > > > tag v5.2\n> > > > > ...\n> > > > > \n> > > > > real\t0m12.727s\n> > > > > user\t0m0.300s\n> > > > > sys\t0m0.371s\n> > > > > \n> > > > > But to get the actual data isn't the problem:\n> > > > > \n> > > > > ukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git show v5.2 | cat\n> > > > > tag v5.2\n> > > > > ...\n> > > > > \n> > > > > real\t0m0.764s\n> > > > > user\t0m0.014s\n> > > > > sys\t0m0.020s\n> > > > > \n> > > > \n> > > > How does 'git --no-pager show v5.2' perform? If it's as fast as the\n> > > > case piping the output to cat, then look into what pager and pager\n> > > > options you use.\n> > > \n> > > \tukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time git --no-pager show v5.2\n> > > \ttag v5.2\n> > > \t...\n> > > \n> > > \treal\t0m13.225s\n> > > \tuser\t0m0.355s\n> > > \tsys\t0m0.336s\n> > > \n> > > So this doesn't seem to be the problem. Also the local configuration\n> > > can be ruled out:\n> > > \n> > > \tukl@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color v5.2\n> > > \ttag v5.2\n> > > \t...\n> > > \n> > > \treal\t0m13.587s\n> > > \tuser\t0m0.335s\n> > > \tsys\t0m0.336s\n> > > \n> > > Thanks\n> > > Uwe\n> > \n> > Have you checked strace output? I see a directory walk through .git/refs\n> > and .git/packed-refs if the output is not redirected.\n> \n> That's a good point, 'git show/log' show decorations (refs pointing to\n> any commits shown) when the output is a terminal:\n> \n> $ git show v5.2\n> [...]\n> commit 0ecfebd2b52404ae0c54a878c872bb93363ada36 (HEAD -> master, tag: v5.2)\n> [...]\n> $ git show v5.2 |cat\n> [...]\n> commit 0ecfebd2b52404ae0c54a878c872bb93363ada36\n> [...]\n\n> And indeed, if you have a lot of refs and cold cache, then that might\n> account for a couple of seconds difference. So, how does 'git show\n> --no-decorate v5.2' perform, and if it performs well, then how many\n> refs do you have ('git for-each-ref |wc -l')?\n\n\t$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color --no-decorate v5.2\n\t...\n\n\treal\t0m1.041s\n\tuser\t0m0.000s\n\tsys\t0m0.021s\n\n\t$ git for-each-ref |wc -l\n\t10013\n\nSo this is indeed the problem.\n\nI'm a bit surprised that the default for --decorate depends on the\noutput being a terminal.\n\nThanks for your help, I will think about what I want to do. Just using\n--no-decorate will work, but isn't nice either. Will test if just\nthrowing away all those tags from linux-next will make this already\nbetter.\n\nBest regards\nUwe\n\n-- \nPengutronix e.K. | Uwe Kleine-König |\nIndustrial Linux Solutions | http://www.pengutronix.de/ |\n"},{"id":"381341","messageId":"20190827103309.GA8571@szeder.dev","threadId":"51755","inReplyTo":"20190827100427.u3a5uvmylm5vddn2@pengutronix.de","subject":"Re: git slow unless piped to cat","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-08-27T10:33:09Z","receivedAt":"2019-08-27T10:33:19Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:\n> I'm a bit surprised that the default for --decorate depends on the\n> output being a terminal.\n\nDecorations (and colors as well) are for humans, and humans read the\nterminal.\n\n> Thanks for your help, I will think about what I want to do. Just using\n> --no-decorate will work, but isn't nice either. Will test if just\n> throwing away all those tags from linux-next will make this already\n> better.\n\nNote that you can disable decorations by setting the 'log.decorate'\nconfiguration variable to false.\n\n"},{"id":"381343","messageId":"20190827105638.2og6vwvqtzkkqn5p@pengutronix.de","threadId":"51755","inReplyTo":"20190827103309.GA8571@szeder.dev","subject":"Re: git slow unless piped to cat","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2019-08-27T10:56:38Z","receivedAt":"2019-08-27T10:56:41Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nOn Tue, Aug 27, 2019 at 12:33:09PM +0200, SZEDER Gábor wrote:\n> On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:\n> > I'm a bit surprised that the default for --decorate depends on the\n> > output being a terminal.\n> \n> Decorations (and colors as well) are for humans, and humans read the\n> terminal.\n\nI agree for colors only. Changing the actually provided information\ndepending on output being a terminal is IMHO at least surprising.\n\n> > Thanks for your help, I will think about what I want to do. Just using\n> > --no-decorate will work, but isn't nice either. Will test if just\n> > throwing away all those tags from linux-next will make this already\n> > better.\n> \n> Note that you can disable decorations by setting the 'log.decorate'\n> configuration variable to false.\n\nBeing able to configure --decorate-refs= and --decorate-refs-exclude= in\nthe config would be nice ...\n\nBest regards\nUwe\n\n-- \nPengutronix e.K. | Uwe Kleine-König |\nIndustrial Linux Solutions | http://www.pengutronix.de/ |\n"},{"id":"381345","messageId":"20190827132804.13350e60@naga","threadId":"51755","inReplyTo":"20190827105638.2og6vwvqtzkkqn5p@pengutronix.de","subject":"Re: git slow unless piped to cat","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2019-08-27T11:28:04Z","receivedAt":"2019-08-27T11:28:08Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, 27 Aug 2019 12:56:38 +0200\nUwe Kleine-König wrote:\n\n> Hello,\n> \n> On Tue, Aug 27, 2019 at 12:33:09PM +0200, SZEDER Gábor wrote:\n> > On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote: \n> > > I'm a bit surprised that the default for --decorate depends on the\n> > > output being a terminal. \n> > \n> > Decorations (and colors as well) are for humans, and humans read the\n> > terminal. \n> \n> I agree for colors only. Changing the actually provided information\n> depending on output being a terminal is IMHO at least surprising.\n> \n> > > Thanks for your help, I will think about what I want to do. Just using\n> > > --no-decorate will work, but isn't nice either. Will test if just\n> > > throwing away all those tags from linux-next will make this already\n> > > better. \n> > \n> > Note that you can disable decorations by setting the 'log.decorate'\n> > configuration variable to false. \n> \n> Being able to configure --decorate-refs= and --decorate-refs-exclude= in\n> the config would be nice ...\n\nThe question is if excluding some will speed things up. Depending on\nthe way they are stored and looked up to match to the commit at hand\nthis might not be a big win.\n\nThanks\n\nMIchal\n"},{"id":"381385","messageId":"20190827185929.GA3150@sigill.intra.peff.net","threadId":"51755","inReplyTo":"20190827100427.u3a5uvmylm5vddn2@pengutronix.de","subject":"Re: git slow unless piped to cat","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-08-27T18:59:30Z","receivedAt":"2019-08-27T18:59:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:\n\n> \t$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color --no-decorate v5.2\n> \t...\n> \n> \treal\t0m1.041s\n> \tuser\t0m0.000s\n> \tsys\t0m0.021s\n> \n> \t$ git for-each-ref |wc -l\n> \t10013\n> \n> So this is indeed the problem.\n\nThat's not that many refs. Are they mostly unpacked? Loose refs are\nawful on a cold cache, since it's one inode per ref (or worse, since it\nhas walk the directories, too).\n\nTry:\n\n find .git/refs -type f | wc -l\n\nto see the loose ones. If there are a lot, try:\n\n git pack-refs --prune --all\n\n(or just \"git gc\", which does this).\n\nModern versions of Git should delete any leftover empty directories\nafter pruning the loose variants, but I think won't go out of their way\nto remove ones they didn't delete from. And those are still expensive to\nwalk on a cold cache. If it's still slow, try:\n\n find .git/refs/* -type d | xargs rmdir -v\n\n-Peff\n"},{"id":"381394","messageId":"20190827213248.kzpszutt46ipboq4@pengutronix.de","threadId":"51755","inReplyTo":"20190827185929.GA3150@sigill.intra.peff.net","subject":"Re: git slow unless piped to cat","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2019-08-27T21:32:48Z","receivedAt":"2019-08-27T21:32:53Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"On Tue, Aug 27, 2019 at 02:59:30PM -0400, Jeff King wrote:\n> On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:\n> \n> > \t$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color --no-decorate v5.2\n> > \t...\n> > \n> > \treal\t0m1.041s\n> > \tuser\t0m0.000s\n> > \tsys\t0m0.021s\n> > \n> > \t$ git for-each-ref |wc -l\n> > \t10013\n> > \n> > So this is indeed the problem.\n> \n> That's not that many refs. Are they mostly unpacked? Loose refs are\n> awful on a cold cache, since it's one inode per ref (or worse, since it\n> has walk the directories, too).\n> \n> Try:\n> \n> find .git/refs -type f | wc -l\n\nukl@dude.ptx:/ptx/src/git/linux.git$ find refs -type f | wc -l \n2874\n\n(Note this is a bare repository. So I used refs instead of .git/refs.)\n\n> to see the loose ones. If there are a lot, try:\n> \n> git pack-refs --prune --all\n> \n> (or just \"git gc\", which does this).\n\nThis is a daily updated mirror that is also incrementally backed up. I\nrepack from time to time, but hesitate to do this regularily as each\ntime I repack the next backup run is \"expensive\" and I get many small\npacks. I did this now anyhow.\n\nAfter that I have:\n\n\t$ find objects/[0-9a-f][0-9a-f] -type f | wc -l\n\t166\n\t$ find objects/pack | wc -l\n\t98\n\n> Modern versions of Git should delete any leftover empty directories\n> after pruning the loose variants, but I think won't go out of their way\n> to remove ones they didn't delete from. And those are still expensive to\n> walk on a cold cache. If it's still slow, try:\n> \n> find .git/refs/* -type d | xargs rmdir -v\n\nThere were a few:\n\n$ find refs/ -depth -type d -empty -print -delete | wc -l\n147\n\n(Oops, after the repacking above this also removed ./refs which I had to\nrestore to make git recognize this as a repository.)\n\nWith these two things done it is a bit faster:\n\n\t$ sudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color v5.2 \n\ttag v5.2\n\n\t...\n\treal\t0m11.022s\n\tuser\t0m0.321s\n\tsys\t0m0.248s\n\nBest regards\nUwe\n\n-- \nPengutronix e.K. | Uwe Kleine-König |\nIndustrial Linux Solutions | http://www.pengutronix.de/ |\n"},{"id":"381395","messageId":"CAGyf7-EaumF+oZFUhNtifrCvqBr1DjcFh8rgQMswcpwip3Bx7w@mail.gmail.com","threadId":"51755","inReplyTo":"20190827213248.kzpszutt46ipboq4@pengutronix.de","subject":"Re: git slow unless piped to cat","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2019-08-27T21:38:57Z","receivedAt":"2019-08-27T21:39:11Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Tue, Aug 27, 2019 at 2:32 PM Uwe Kleine-König\n wrote:\n>\n> On Tue, Aug 27, 2019 at 02:59:30PM -0400, Jeff King wrote:\n> > On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:\n> >\n> > to see the loose ones. If there are a lot, try:\n> >\n> > git pack-refs --prune --all\n> >\n> > (or just \"git gc\", which does this).\n>\n> This is a daily updated mirror that is also incrementally backed up. I\n> repack from time to time, but hesitate to do this regularily as each\n> time I repack the next backup run is \"expensive\" and I get many small\n> packs. I did this now anyhow.\n\nJust noting that Jeff didn't suggest a repack; he suggested a\npack-refs. This should have little, if any impact on your backup\nprocessing, because all it's going to do is rewrite the \"packed-refs\"\nfile and delete loose refs. It doesn't modify any files under objects/\nat all.\n\nBryan\n"},{"id":"381430","messageId":"20190828102417.un2hjuizfmu3n7ya@pengutronix.de","threadId":"51755","inReplyTo":"CAGyf7-EaumF+oZFUhNtifrCvqBr1DjcFh8rgQMswcpwip3Bx7w@mail.gmail.com","subject":"Re: git slow unless piped to cat","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2019-08-28T10:24:17Z","receivedAt":"2019-08-28T10:24:37Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nOn Tue, Aug 27, 2019 at 02:38:57PM -0700, Bryan Turner wrote:\n> On Tue, Aug 27, 2019 at 2:32 PM Uwe Kleine-König\n> wrote:\n> >\n> > On Tue, Aug 27, 2019 at 02:59:30PM -0400, Jeff King wrote:\n> > > On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:\n> > >\n> > > to see the loose ones. If there are a lot, try:\n> > >\n> > > git pack-refs --prune --all\n> > >\n> > > (or just \"git gc\", which does this).\n> >\n> > This is a daily updated mirror that is also incrementally backed up. I\n> > repack from time to time, but hesitate to do this regularily as each\n> > time I repack the next backup run is \"expensive\" and I get many small\n> > packs. I did this now anyhow.\n> \n> Just noting that Jeff didn't suggest a repack; he suggested a\n> pack-refs. This should have little, if any impact on your backup\n> processing, because all it's going to do is rewrite the \"packed-refs\"\n> file and delete loose refs. It doesn't modify any files under objects/\n> at all.\n\nAh, right. That also explains why I still had a few loose objects. I\ncut-n-pasted the command, so I did as suggested, just thought it was\nsomething different.\n\nThanks\nUwe\n\n-- \nPengutronix e.K. | Uwe Kleine-König |\nIndustrial Linux Solutions | http://www.pengutronix.de/ |\n"}]}