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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html