Re: Understanding version 4 packs

From: Shawn O. Pearce <spearce@spearce.org>
Date: Mar 25, 2007, 09:40 UTC
Message-ID: <20070325094033.GJ25863@spearce.org>
In-Reply-To: <20070325084641.GG25863@spearce.org>

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

Show 5 quoted lines

> So what you will find is that the EXTOBJ_FILENAME_TABLE is dumped
> out behind all of the commits, but before the first OBJ_DICT_TREE,
> and since all trees tend to get converted to an OBJ_DICT_TREE,
> the EXTOBJ_FILENAME_TABLE is sandwiched exactly between the commits
> and the trees.

...

Show 8 quoted lines

> The reason we put the EXTOBJ_FILENAME_TABLE behind the commits is
> we often walk the commit chains (following parent pointers) without
> looking at the trees at all.  Consider `git log`, in the default
> settings we don't need the trees.  By keeping the filename table
> behind the commits the OS read-ahead buffering gets a better chance
> at loading all of the data we need, and none of the data we don't.
> 
> So that's why its where it is.

I just talked with Junio about this on #git.

My real reason for putting the EXTOBJ_FILENAME_TABLE here is "lack of a better reason". I just didn't write that above. ;-)

We want it before the first OBJ_DICT_TREE to help the unpackers.

And just like we don't currently ever store the delta base for an OBJ_TREE before the first commit (as commits always get packed first) we also don't store the EXTOBJ_FILENAME_TREE before the first commit.

Junio raised the point that in large projects `git log -- asm/i386` can be a very common/useful/necessary operation, and that in such cases we need to evaluate trees as part of the log operation. Any attempt to optimize for git-log without a path spec is wrong, wrong, wrong. I agree.

The part I quoted above was not trying to imply that Nico and I are optimizing for using git-log without a path limiter. It just read that way to Junio, and may read that way for others too. Hence this follow-up.

I'm open to suggestions about placement for EXTOBJ_FILENAME_TABLE, but I think its current position between commits and trees is the probably the best we can get.

-- 
Shawn.