Re: [PATCH 10/12] line-log: more responsive, incremental 'git log -L'

>> 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

>> 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?