On 5/4/2020 1:52 PM, Taylor Blau wrote: > On Fri, May 01, 2020 at 03:30:27PM +0000, SZEDER Gábor via GitGitGadget wrote: >> To be clear: this patch doesn't actually optimize the line-level log, >> but merely moves most of the work from the preprocessing step to the >> history travelsal, so the commits modifying the line range can be > > s/travelsal/traversal Thanks! >> shown as soon as they are processed, and the traversal can be >> terminated as soon as the given number of commits are shown. >> Consequently, listing the full history of a line range, potentially >> all the way to the root commit, will take the same time as before (but >> at least the user might start reading the output earlier). >> Furthermore, if the most recent commit modifying the line range is far >> away from the starting revision, then that initial delay will still be >> significant. >> >> Additional testing by Derrick Stolee: In the Linux kernel repository, >> the MAINTAINERS file was changed ~3,500 times across the ~915,000 >> commits. In addition to that edit frequency, the file itself is quite >> large (~18,700 lines). This means that a significant portion of the >> computation is taken up by computing the patch-diff of the file. This >> patch improves the time it takes to output the first result quite a >> bit: >> >> Command: git log -L 100,200:MAINTAINERS -n 1 >/dev/null >> Before: 3.88 s >> After: 0.71 s > > Are these 'real' times, or user/sys times? True, this is a difference between my reporting and Szeder's. I only report "real" time. Thanks, -Stolee
