Re: Make the git codebase thread-safe

> On Thu, Feb 13, 2014 at 07:04:02AM +0100, David Kastrup wrote:
> > Mike Hommey <mh@glandium.org> writes:
> > 
> > > On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
> > >> Stefan Zager <szager@chromium.org> writes:
> > >> 
> > >> > On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup <dak@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.
> 
> Sorry, I thought you were talking about write operations, not reads.