Re: More precise tag following

From: Junio C Hamano <junkio@cox.net>
Date: Jan 27, 2007, 08:41 UTC
Message-ID: <7vbqkklv3h.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070127080126.GC9966@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Based on some (limited) profiling with Shark it seems we spend about
> 50% of our CPU time doing zlib decompression of objects and almost
> another 14% parsing the tree objects to apply the path limiter.

I once tried to use zlib compression level 0 for tree objects and did not see much difference -- maybe I should dig it up and find out why.

Show 5 quoted lines

> One idea Simon and I were talking about was to store a reverse
> file/tree-level DAG in the header of each tree/blob object in the
> pack file.
> ...
> Thoughts?

Anything you would do, storing that in tree is wrong. Tree object only represents just the contents of a single state and in itself there should not be any information that describes its relation with other trees [*1*].

And of course making it pack-only is doubly wrong.

*1* That's why my thinking-aloud talked about "N list of changed paths recorded in a commit object with N parents". A commit is to talk about one particular state (i.e. tree) and its relation to other commits (and by indirection, other trees), so logically the information could belong there --- that is merely a "could", since that is strictly caching for performance. After finding where the bottleneck is, obviously finding a way to optimize the tree pathlimiting with the currently available data without having such redundant data is more preferable.