Why is --graph --max-count=n so much slower than --graph HEAD~n..?

Why is --graph --max-count=n so much slower than --graph HEAD~n..?

[Mitchel Humpherys]

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

Re: Why is --graph --max-count=n so much slower than --graph HEAD~n..?

[Junio C Hamano]

Mitchel Humpherys <mitch.special@gmail.com> 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.

Re: Why is --graph --max-count=n so much slower than --graph HEAD~n..?

[Mitchel Humpherys]

On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Mitchel Humpherys <mitch.special@gmail.com> 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

Re: Why is --graph --max-count=n so much slower than --graph HEAD~n..?

[Junio C Hamano]

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
<mitch.special@gmail.com> wrote:
> On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Mitchel Humpherys <mitch.special@gmail.com> 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