From: Linus Torvalds Date: Tue, 31 Jan 2006 21:25:08 GMT Subject: Re: [Census] So who uses git? Message-ID: In-Reply-To: <20060130225107.GA3857@limbo.home> On Mon, 30 Jan 2006, Alex Riesen wrote: > > I use git in cygwin for a project with more then 17k files (almost 6M lines). > It's real slow on ntfs (on 3.2Mhz PIV!) One thing that git does rely on is a fast "lstat()" system call. The index file means that we almost never need to read the contents of a file to compare, but git _does_ check that files haven't been modified, and doing an "lstat()" on every single file it knows about is the way to do that. Now, I suspect that you simply can't do basic filename lookups much faster than Linux does them. The Linux VFS layer name caching reigns supreme: the dentries are just incredibly powerful, and the reason Linux kicks ass on many benchmarks. And yes, git was designed for it. git is _really_ fast on Linux, but any operating system that is so stupid that it has to call down to the low-level filesystem for filename lookup (which is most of them, and from what I have heard, the NT VFS layer is worse than most) will take a lot longer. This is sadly not something I think you can possibly avoid. Git is literally being as fast as is humanly possible without doing explicit locking. You _can_ avoid the "lstat()" calls if you are willing to always explicitly mark files that you have changed (so that the SCM can stat just _those_ files and ignore all the others), but I personally much prefer being able to use any random tools on the files without having to prepare them some way. So we could speed it up on cygwin (and yes, it would speed git up a lot even on Linux, but since the cached lstat() case is so fast anyway, I doubt a lot of Linux users care - the biggest win would be on a cold-cache tree). But it would require that you explicitly _mark_ the files you edit some way. Btw, BK wanted that, and it wasn't _too_ painful. You had to do bk edit to mark a file as being ready to be dirtied, and as a helper command you would use bk editor which would first do the "bk edit" thing and then start up your favourite editor (the usual ${EDITOR:${VISUAL:vi}} rules applied) on it, and it worked fine. We _could_ do the same in git. I'd just prefer not to. For small projects (or big projects with fairly few files), it really shouldn't matter. Your 17k files example is hopefully fairly rare.. > But its more intuitive and more powerful than any alternatives here (Perforce, > SVN and CVS come to mind). Good to know. Linus