Jim Raden wrote: > As everyone is aware, git is slower on Windows than on Linux. My > question is this: would an ext2fs partition on my Windows machine > speed up git on Windows? (Not that it's that slow -- it's just that > I'm a bit jealous of those amazingly fast operations on Linux, and > faster is better, no?)
Just changing the underlying filesystem driver won't change the API. Let's take stat() for example: the st_ino member in struct stat will still always be zero, and st_nlink will always be 1. You have to remember that this function "stat" doesn't exist on Windows as a syscall in any form, it is implemented in userspace by the C runtime (MSVCRT) in terms of the Win32 API, using FindFirstFile[1] in this case. And FindFirstFile fills in a struct WIN32_FIND_DATA[2] which has no members to indicate inode or number of links. So the 'stat' in MSVCRT can do nothing but fill them in as 0 and 1 always, and so any code in git that might get a speedup from being able to efficiently get st_ino from stat will still be equally useless. On Windows if you want the inode and number of links you have to first open the file and then call GetFileInformationByHandle[3]. A different implementation of 'stat' could in fact do this, and it would be able to return a sensible "struct stat" with correct and meaningful values even for NTFS -- it would just be a lot slower. And in fact this is what Cygwin does, since Cygwin doesn't use anything in MSVCRT but implements it on its own. Anyway, my original point is that the details of the underlying filesystem cannot matter, because it's an architectural problem: the design of the API does not allow to get something like the unique inode number from the filesystem driver without first opening the file. Brian [1] http://msdn2.microsoft.com/en-us/library/aa364418.aspx [2] http://msdn2.microsoft.com/en-us/library/aa365740.aspx [3] http://msdn2.microsoft.com/en-us/library/aa364952.aspx
