Re: [PATCH v6 00/14] Serialized Git Commit Graph

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Mar 14 2018, Derrick Stolee jotted:

> Hopefully this version is ready to merge. I have several follow-up topics
> in mind to submit soon after, including:

I've been doing some preliminary testing of this internally, all good so
far, on a relatively small repo (~100k commits) I was using for testing:

    - git -c core.commitGraph=true -C <repo> rev-list --all:
        -      /mnt/ext4_graph => min:273    mean:279    max:389    -- (273 274 275 276 277 279 282 282 345 389)
        -            /mnt/ext4 => min:1087   mean:1123   max:1175   -- (1087 1092 1092 1104 1117 1123 1126 1136 1143 1175)

This is on a fresh clone with one giant pack and where the commit graph
data was generated afterwards with "git commit-graph write" for the
*_graph repo, so it contains all the commits.

So less than 25% of the mean time it spent before. Nice. Those are times
in milliseconds over 10 runs, for this particular one I didn't get much
of an improvement in --graph, but still ~10%:

    - git -c core.commitGraph=true -C <repo> log --oneline --graph:
        -      /mnt/ext4_graph => min:1420   mean:1449   max:1586   -- (1420 1423 1428 1434 1449 1449 1490 1548 1567 1586)
        -            /mnt/ext4 => min:1547   mean:1616   max:2136   -- (1547 1557 1581 1585 1598 1616 1621 1740 1964 2136)

I noticed that it takes a *long* time to generate the graph, on a bigger
repo I have it takes 20 minutes, and this is a repo where repack -A -d
itself takes 5-8 minutes, probably on the upper end of that with the
bitmap, but once you do that it's relatively snappy with --stdin-commits
--additive when I feed it the new commits.

I don't have any need really to make this run in 10m instead of 20m,
just something I found interesting, i.e. how it compares to the repack
itself.