# Why is --graph --max-count=n so much slower than --graph HEAD~n..? 4 messages from 2014-05-20 to 2014-05-21. Participants: Mitchel Humpherys, Junio C Hamano. Thread: https://gitlist.dev/t/36715 ## Mitchel Humpherys, 2014-05-20 22:17 Subject: Why is --graph --max-count=n so much slower than --graph HEAD~n..? Message-ID: URL: https://gitlist.dev/e/vnkwd2f8ayea.fsf%40mitchelh-linux.qualcomm.com ``` I've noticed that --max-count doesn't seem to speed up `git log --graph' computation time. Here are some numbers using the linux kernel repository: | command | time* | |----------------------------------+-------| | git log --graph --max-count=5000 | 4.11s | | git log --graph --max-count=1000 | 4.05s | | git log --graph --max-count=500 | 3.95s | | git log --graph --max-count=50 | 3.95s | | git log --graph --max-count=10 | 3.97s | | git log --graph --max-count=1 | 3.96s | However, specifying a manual revision range results in a much more dramatic speedup as `n' decreases: | command | time* | |----------------------------------+-------| | git log --graph HEAD~5000.. | 6.69s | | git log --graph HEAD~1000.. | 1.89s | | git log --graph HEAD~500.. | 0.03s | | git log --graph HEAD~50.. | 0.02s | | git log --graph HEAD~10.. | 0.02s | | git log --graph HEAD~1.. | 0.00s | * All times are "steady state" measurements after warming up the disk cache by running the command a few times. I see that the manual revision range doesn't seem to go back as far in history when I diff the output of the two commands. However, if I add `--max-count=50' to the `HEAD~50..' command I get the exact same commits but with fewer "dangling" lines at the bottom of the graph in the `HEAD~50..' approach. Anyone care to provide any insight about what's going on here? Is this expected behavior? Is there any low-hanging fruit for optimizing --max-count --graph? -- Mitch ``` ## Junio C Hamano, 2014-05-20 22:50 Subject: Re: Why is --graph --max-count=n so much slower than --graph HEAD~n..? Message-ID: URL: https://gitlist.dev/e/xmqq61l0rrng.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` Mitchel Humpherys writes: > I've noticed that --max-count doesn't seem to speed up `git log --graph' > computation time. AFAIK, --graph wants to compute the whole history and the max-count only affects the output phase after --graph does its computation. Besides, "log --max-count=n" and "log HEAD~n.." compute completely different things, so the comparison is apples and oranges. ``` ## Mitchel Humpherys, 2014-05-21 00:13 Subject: Re: Why is --graph --max-count=n so much slower than --graph HEAD~n..? Message-ID: URL: https://gitlist.dev/e/vnkw4n0kat01.fsf%40mitchelh-linux.qualcomm.com In-Reply-To: ``` On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano wrote: > Mitchel Humpherys writes: > >> I've noticed that --max-count doesn't seem to speed up `git log --graph' >> computation time. > > AFAIK, --graph wants to compute the whole history and the max-count > only affects the output phase after --graph does its computation. > > Besides, "log --max-count=n" and "log HEAD~n.." compute completely > different things, so the comparison is apples and oranges. Yes, apples and oranges in a black box :). I provided the HEAD~n.. measurements just to show that we can get (almost) the exact same output another way and it's much faster. It just "seems like" --max-count=n should speed things up as n decreases... -- Mitch ``` ## Junio C Hamano, 2014-05-21 00:24 Subject: Re: Why is --graph --max-count=n so much slower than --graph HEAD~n..? Message-ID: URL: https://gitlist.dev/e/CAPc5daWBKa2kTe6jEcNk2%3DXqh%2BR-mMFqL2tTpHERtPjPkAAvGg%40mail.gmail.com In-Reply-To: ``` Surely. I am on a bus with terrible WiFi that does not let me use the usual terminal, but you would find a code in revision.c that sets revs->topo_order = 1 when it parses "--graph" option. If you disable it, that would stop "--graph" from wanting to compute the whole history before starting to emit stuff (and then stop at nth one with --max-count). I do not know what other side effects such a change would have, though. On Tue, May 20, 2014 at 5:13 PM, Mitchel Humpherys wrote: > On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano wrote: >> Mitchel Humpherys writes: >> >>> I've noticed that --max-count doesn't seem to speed up `git log --graph' >>> computation time. >> >> AFAIK, --graph wants to compute the whole history and the max-count >> only affects the output phase after --graph does its computation. >> >> Besides, "log --max-count=n" and "log HEAD~n.." compute completely >> different things, so the comparison is apples and oranges. > > Yes, apples and oranges in a black box :). I provided the > HEAD~n.. measurements just to show that we can get (almost) the exact > same output another way and it's much faster. It just "seems like" > --max-count=n should speed things up as n decreases... > > > -- > Mitch ```