Re: Is cogito really this inefficient

From: Russell King <rmk@arm.linux.org.uk>
Date: Jul 14, 2005, 09:59 UTC
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:

Show 9 quoted lines

> 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