Mike Hommey <[email protected]> writes:
> On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
>> Stefan Zager <[email protected]> writes:
>>
>> > On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup <[email protected]> wrote:
>> >
>> >> Really, give the above patch a try. I am taking longer to finish it
>> >> than anticipated (with a lot due to procrastination but that is,
>> >> unfortunately, a large part of my workflow), and it's cutting into my
>> >> "paychecks" (voluntary donations which to a good degree depend on timely
>> >> and nontrivial progress reports for my freely available work on GNU
>> >> LilyPond).
>> >
>> > I will give that a try. How much of a performance improvement have
>> > you clocked?
>>
>> Depends on file type and size. With large files with lots of small
>> changes, performance improvements get more impressive.
>>
>> Some ugly real-world examples are the Emacs repository, src/xdisp.c
>> (performance improvement about a factor of 3), a large file in the style
>> of /usr/share/dict/words clocking in at a factor of about 5.
>>
>> Again, that's with an SSD and ext4 filesystem on GNU/Linux, and there
>> are no improvements in system time (I/O) except for patch 4 of the
>> series which helps perhaps 20% or so.
>>
>> So the benefits of the patch will come into play mostly for big, bad
>> files on Windows: other than that, the I/O time is likely to be the
>> dominant player anyway.
>
> How much fragmentation does that add to the files, though?
Uh, git-blame is a read-only operation. It does not add fragmentation
to any file. The patch will add a diff of probably a few dozen hunks to
builtin/blame.c. Do you call that "fragmentation"? It is small enough
that I expect even
git blame builtin/blame.c
to be faster than before. But that interpretation of your question
probably tries to make too much sense out of what is just nonsense in
the given context.
--
David Kastrup
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
