Re: [PATCH] write-tree performance problems

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 20, 2005, 19:47 UTC
Message-ID: <Pine.LNX.4.58.0504201237340.6467@ppc970.osdl.org>
In-Reply-To: <Pine.LNX.4.58.0504201218360.6467@ppc970.osdl.org>

On Wed, 20 Apr 2005, Linus Torvalds wrote:

>
> It would be nicer for the cache to make the index file "header" be a 
> "footer", and write it out last - that way we'd be able to do the SHA1 as 
> we write rather than doing a two-pass thing. That's for another time.

That other time was now.

The header is still a header, but the sha1 is now at the end of the file, which means that the header version has been incremented by 1 (to 2).

This is also sadly an incompatible change, so once you update and install the new tools, you'll need to do

	tree=$(cat-file commit $(cat .git/HEAD) | sed 's/tree //;q')
	read-tree $tree
	update-cache --refresh

to re-build your index file.

Sorry about that, but the end result should be quite fast (especially if your sha1 is fast). The best benchmark is probably to just do a "time update-cache Makefile" in the kernel (before and after), when the cache was already up-to-date and with no time spent on stating lots of files. That kind of "one file changed" timing is actually the common case (in this case Makefile won't have changed, but update-cache doesn't care).

(Of course, I could optimize it to notice that the update-cache didn't do anything and avoid the write altogether, but that's likely optimizing for the wrong case, since normally you'd call update-cache when you know something changed).

Yeah, it's somewhat silly doing optimizations at this point, but I want to make sure that the data structures are all ready for a real release, and as part of that I want to make sure there are no stupid low-hanging fruit that we'll curse later. Better get it done with now.

			Linus