On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano [off-list ref] wrote:
Mitchel Humpherys [off-list ref] writes:
quoted
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
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
[off-list ref] wrote:
On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano [off-list ref] wrote:
quoted
Mitchel Humpherys [off-list ref] writes:
quoted
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