"Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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. > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html