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

On Wed, Mar 14 2018, Derrick Stolee jotted:

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.