Mike Hommey <m...@glandium.org> writes:

> On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
>> Stefan Zager <sza...@chromium.org> writes:
>> > On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup <d...@gnu.org> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to