From: Russell King <rmk@arm.linux.org.uk>
Date: Thu, 14 Jul 2005 09:59:38 GMT
Subject: Re: Is cogito really this inefficient
Message-ID: <20050714105938.A31383@flint.arm.linux.org.uk>
In-Reply-To: <tnxu0ixoiuo.fsf@arm.com>

On Thu, Jul 14, 2005 at 10:08:31AM +0100, Catalin Marinas wrote:
> Russell King <rmk@arm.linux.org.uk> wrote:
> > it appears that cg-diff does a
> >
> > 	git-update-cache --refresh >/dev/null
> >
> > each time it's run, which is taking the bulk of the time.  Also note
> > that curiously, it exits with status 1.
> 
> Does git-ls-files --unmerged show any files?

No, and it returns fairly quickly:

$ /usr/bin/time git-ls-files --unmerged
0.29user 0.03system 0:00.43elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+655minor)pagefaults 0swaps

Actually, I should've left the sh -x /usr/bin/cg-diff drivers/serial/8250.c
running a little longer.  It's not the git-update-cache command which
is taking the time, it's git-diff-cache.

Running the diff several times, both with and without changes to
drivers/serial/8250.c, it seems that sometimes it's faster.  I guess
it has to do with dentry invalidation...

However, the point is - I've only asked for _one_ file.  Why do we need
to look at _every_ file in the tree?

I could understand this behaviour if I'd asked for a diff across the
whole tree, but I didn't.

Internally, the sha1 of the unmodified drivers/serial/8250.c should be
known, so should be trivial to unpack that and generate a diff.  Given
the cache, this should be something which should be lightning fast
when the requested fileset to diff is already known.

-- 
Russell King