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.
