Message ID | pull.25.v4.git.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Use generation numbers for --topo-order | expand |
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > This patch series performs a decently-sized refactoring of the revision-walk > machinery. Well, "refactoring" is probably the wrong word, as I don't > actually remove the old code. Instead, when we see certain options in the > 'rev_info' struct, we redirect the commit-walk logic to a new set of methods > that distribute the workload differently. By using generation numbers in the > commit-graph, we can significantly improve 'git log --graph' commands (and > the underlying 'git rev-list --topo-order'). > > On the Linux repository, I got the following performance results when > comparing to the previous version with or without a commit-graph: > > Test: git rev-list --topo-order -100 HEAD > HEAD~1, no commit-graph: 6.80 s > HEAD~1, w/ commit-graph: 0.77 s > HEAD, w/ commit-graph: 0.02 s > > Test: git rev-list --topo-order -100 HEAD -- tools > HEAD~1, no commit-graph: 9.63 s > HEAD~1, w/ commit-graph: 6.06 s > HEAD, w/ commit-graph: 0.06 s I wonder if we could make use of existing infrstructure in 't/perf/' to perform those benchmarks for us (perhaps augmented with large repository, and only if requested -- similarly to how long tests are handled). -- Jakub Narębski
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > This patch series performs a decently-sized refactoring of the revision-walk > machinery. Well, "refactoring" is probably the wrong word, as I don't > actually remove the old code. Instead, when we see certain options in the > 'rev_info' struct, we redirect the commit-walk logic to a new set of methods > that distribute the workload differently. By using generation numbers in the > commit-graph, we can significantly improve 'git log --graph' commands (and > the underlying 'git rev-list --topo-order'). Review discussions seem to have petered out. Would we merge this to 'next' and start cooking, perhaps for the remainder of this cycle?
On 11/1/2018 1:21 AM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> This patch series performs a decently-sized refactoring of the revision-walk >> machinery. Well, "refactoring" is probably the wrong word, as I don't >> actually remove the old code. Instead, when we see certain options in the >> 'rev_info' struct, we redirect the commit-walk logic to a new set of methods >> that distribute the workload differently. By using generation numbers in the >> commit-graph, we can significantly improve 'git log --graph' commands (and >> the underlying 'git rev-list --topo-order'). > Review discussions seem to have petered out. Would we merge this to > 'next' and start cooking, perhaps for the remainder of this cycle? Thanks, but I've just sent a v5 responding to Jakub's feedback on v4. [1] I'd be happy to let it sit in next until you feel it has cooked long enough. I'm available to respond to feedback in the form of new topics. Thanks, -Stolee [1] https://public-inbox.org/git/20181101134623.84055-1-dstolee@microsoft.com/T/#u
Derrick Stolee <stolee@gmail.com> writes: >> Review discussions seem to have petered out. Would we merge this to >> 'next' and start cooking, perhaps for the remainder of this cycle? > > Thanks, but I've just sent a v5 responding to Jakub's feedback on v4. [1] > > I'd be happy to let it sit in next until you feel it has cooked long > enough. I'm available to respond to feedback in the form of new > topics. OK. I'm quite happy to see this round of review helped greatly by Jakub, by the way. THanks, both.