From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Hommey Subject: Re: Make the git codebase thread-safe Date: Thu, 13 Feb 2014 18:48:46 +0900 Message-ID: <20140213094846.GB15366@glandium.org> References: <87y51g88sc.fsf@fencepost.gnu.org> <87ppms87n7.fsf@fencepost.gnu.org> <20140212230909.GB7208@glandium.org> <87lhxf8s6l.fsf@fencepost.gnu.org> <20140213093439.GA15366@glandium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stefan Zager , Duy Nguyen , Git Mailing List To: David Kastrup X-From: git-owner@vger.kernel.org Thu Feb 13 10:49:13 2014 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WDsut-0008IE-Qx for gcvg-git-2@plane.gmane.org; Thu, 13 Feb 2014 10:49:12 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753813AbaBMJtE (ORCPT ); Thu, 13 Feb 2014 04:49:04 -0500 Received: from ks3293202.kimsufi.com ([5.135.186.141]:37565 "EHLO zenigata.glandium.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753808AbaBMJtB (ORCPT ); Thu, 13 Feb 2014 04:49:01 -0500 Received: from glandium by zenigata.glandium.org with local (Exim 4.82) (envelope-from ) id 1WDsuV-00043H-7k; Thu, 13 Feb 2014 18:48:47 +0900 Content-Disposition: inline In-Reply-To: <20140213093439.GA15366@glandium.org> X-GPG-Fingerprint: 182E 161D 1130 B9FC CD7D B167 E42A A04F A6AA 8C72 User-Agent: Mutt/1.5.21 (2010-09-15) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Thu, Feb 13, 2014 at 06:34:39PM +0900, Mike Hommey wrote: > On Thu, Feb 13, 2014 at 07:04:02AM +0100, David Kastrup wrote: > > Mike Hommey writes: > > > > > On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote: > > >> Stefan Zager writes: > > >> > > >> > On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup 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. Specifically, I thought you were talking about git checkout. Mike