tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: End-user VCS thoughts

Roy Marples <> writes:

> git diff .
> Is a quite fast when you drill down a directory or two.
> status and log sadly do operate on the whole repository.
> For the log operation I tend to prefer a web view, which is normally
> very quick.
> I rarely use status (in cvs or other) so I don't know how to get you the
> same data faster.

git log is fast.  I just ran "git log -1" in a repo that has all of
netbsd and all of pkgsrc, plus other stuff, after not having touched it
for a while, and it took 0.013s.  Repeating it took 0.005s.  I am not
surprised by this; the log is availabl from the head ref with a few
accesses.  Repeating with -20, and > /dev/null, I saw 0.014s and 0.04s.
With -1000, 0.216s and 0.028s.  (I would expect hg to be similar, but I
haven't tried it.)

The problem with "git status" is that it has to report on whether any
in-repo file is modified, and if there are any stray files in any
directory.  Straigthforwardly, and in the current code, this requires a
tremendous number of stat calls.  (stat on NetBSD is slower than on
Linux, and it would be nice to speed it up.)  There has been talk of
some sort of inotify daemon that git could consult, so that it could
know that some set of inodes hasn't been touched, but I am unclear on

You can do "git status ." to find out about only the current subtree.
In netinet, with a cold cache, that took 0.688s.  Repeating, it took
0.678s.  This seems high; I'm not sure how much it's doing with the rest
of the index.   Running on my entire tree, it took 9.5s.  Then 2.25s and
2.02s.   Keep in mind this is a repo that is *bigger* than NetBSD's,
with about 400K files.  If kern.maxvnodes is bigger than the repo size,
this gets faster.

Again I would expect hg to be similar, since it has to answer the same
question.  Also, the equivalent operation in CVS is "cvs up -n", which
takes far far longer and requires the network.

I suspect it's possible to make git deal better with flaky links; it's
fundamentally about pushing a bunch of objects each of which isn't that

Attachment: pgpPalKqScNrk.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index