On Thu, Feb 13, 2014 at 07:04:02AM +0100, David Kastrup wrote: > 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.
Sorry, I thought you were talking about write operations, not reads. Mike -- 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
