On Tue, 16 Oct 2007, Eli Zaretskii wrote:
> > Date: Tue, 16 Oct 2007 07:14:56 +0200
> > From: Andreas Ericsson <ae@xxxxxx>
> > CC: Daniel Barkalow <barkalow@xxxxxxxxxxxx>, raa.lkml@xxxxxxxxx,
> > Johannes.Schindelin@xxxxxx, tsuna@xxxxxxxxxxxxx, git@xxxxxxxxxxxxxxx,
> > make-w32@xxxxxxx
> >
> > > Sorry I'm asking potentially stupid questions out of ignorance: why
> > > would you want readdir to return `README' when you have `readme'?
> > >
> >
> > Because it might have been checked in as README, and since git is case
> > sensitive that is what it'll think should be there when it reads the
> > directories. If it's not, users get to see
> >
> > removed: README
> > untracked: readme
>
> This is a non-issue, then: Windows filesystems are case-preserving, so
> if `README' became `readme', someone deliberately renamed it, in which
> case it's okay for git to react as above.
>
> > could be an intentional rename, but we don't know for sure.
>
> It _must_ have been an intentional rename. While years ago there used
> to be old DOS programs that could cause such a rename as a side effect
> of modifying a file, that time is long gone. There's no longer a need
> to cater to such programs, as even DOS programs can support
> case-preserving APIs on Windows.
I'm partially worried about cases where checking out a "README" fails to
replace the name of an existing "readme", or something of that sort.
> > To be honest though, there are so many places which do the readdir+stat
> > that I don't think it'd be worth factoring it out
>
> Something for Windows users to decide, I guess. It's not hard to
> refactor this, it just needs a motivated volunteer.
>
> > especially since it
> > *works* on windows. It's just slow, and only slow compared to various
> > unices.
>
> I think only the Linux filesystem is as fast as you say. But I may be
> wrong (did someone compare with *BSD, say?).
I think you're right (nothing else can compete with Linux for doing half a
million trivial syscalls), but other unixes aren't terrible, either.
IIRC, on OS X, we had problems when we were doing 4 times as many syscalls
as necessary, but was fine with that fixed.
> > I *think* (correct me if I'm wrong) that git is still faster
> > than a whole bunch of other scm's on windows, but to one who's used to
> > its performance on Linux that waiting several seconds to scan 10k files
> > just feels wrong.
>
> Unless that 10K is a typo and you really meant 100K, I don't think 10K
> files should take several seconds to scan on Windows. I just tried
> "find -print" on a directory with 32K files in 4K subdirectories, and
> it took 8 sec elapsed with a hot cache. So 10K files should take at
> most 2 seconds, even without optimizing file traversal code. Doing
> the same with native Windows system calls ("dir /s") brings that down
> to 4 seconds for 32K files.
>
> On the other hand, what packages have 100K files? If there's only one
> -- the Linux kernel -- then I think this kind of performance is for
> all practical purposes unimportant on Windows, because while it is
> reasonable to assume that someone would like to use git on Windows,
> assuming that someone will develop the Linux kernel on Windows is --
> how should I put it -- _really_ far-fetched ;-)
Actually, there are a number of projects much bigger than the Linux
kernel; I think KDE was considering using git, and wanted Windows support,
and KDE is insanely huge, mostly as a result of having one big repository
for everything.
> As for speed of file ops ``just feeling wrong'': it's not limited to
> git in any way. You will see the same with "tar -x", with "find" and
> even with "cp -r", when you compare Linux filesystems, especially on a
> fast 64-bit machine, with comparable Windows operations. A Windows
> user who occasionally works on GNU/Linux already knows that, so seeing
> the same in git will not come as a surprise. Again, I wonder how this
> compares with other free OSes, like FreeBSD (unless they use the same
> filesystem), and with proprietary Unices, like AIX and Solaris.
For most things, Unix filesystems are fast enough that the bulk of the
time is spent elsewhere. "git status" without any changes and a hot cache
is unusual in being both a common operation and entirely trivial syscalls
if the filesystem makes it efficient.
The problem we've had is that Linux users who occasionally work on Windows
say git seems impossibly slow on Windows.
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
