From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Barkalow Subject: Re: git performance Date: Thu, 23 Oct 2008 23:56:46 -0400 (EDT) Message-ID: References: <000801c93483$2fdad340$8f9079c0$@com> <20081022203624.GA4585@coredump.intra.peff.net> <000901c93490$e0c40ed0$a24c2c70$@com> <20081024072412.6117@nanako3.lavabit.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Edward Ned Harvey , git@vger.kernel.org To: Nanako Shiraishi X-From: git-owner@vger.kernel.org Fri Oct 24 05:59:08 2008 connect(): Connection refused Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1KtDpH-0007rS-1a for gcvg-git-2@gmane.org; Fri, 24 Oct 2008 05:59:03 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751685AbYJXD4t (ORCPT ); Thu, 23 Oct 2008 23:56:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751651AbYJXD4t (ORCPT ); Thu, 23 Oct 2008 23:56:49 -0400 Received: from iabervon.org ([66.92.72.58]:37956 "EHLO iabervon.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751423AbYJXD4s (ORCPT ); Thu, 23 Oct 2008 23:56:48 -0400 Received: (qmail 3010 invoked by uid 1000); 24 Oct 2008 03:56:46 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 24 Oct 2008 03:56:46 -0000 In-Reply-To: <20081024072412.6117@nanako3.lavabit.com> User-Agent: Alpine 1.00 (LNX 882 2007-12-20) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Fri, 24 Oct 2008, Nanako Shiraishi wrote: > Quoting Daniel Barkalow : > > > On Wed, 22 Oct 2008, Edward Ned Harvey wrote: > > > >> Out of curiosity, what are they talking about, when they say "git is > >> fast?" Just the fact that it's all local disk, or is there more to it > >> than that? I could see - git would probably outperform perforce for > >> versioning of large files (let's say iso files) to benefit from > >> sustained local disk IO, while perforce would probably outperform > >> anything I can think of, operating on thousands of tiny files, because > >> it will never walk the tree. > > > > It shouldn't be too hard to make git work like perforce with respect to > > walking the tree. git keeps an index of the stat() info it saw when it > > last looked at files, and only looks at the contents of files whose stat() > > info has changed. In order to have it work like perforce, it would just > > need to have a flag in the stat() info index for "don't even bother", > > Are you describing the "assume unchanged bit"? Yes, but with the user write mode bit in the filesystem set to no-assume-unchanged, which is how Perforce users cope with it. I hadn't realized it had been implemented to get set on a per-file basis, rather than just as a global setting that caused it to not stat() anything except right when it was told to update. -Daniel *This .sig left intentionally blank*