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

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?