Re: Why do base objects appear behind the delta in packs?
- From
Junio C Hamano <junkio@cox.net>
- Date
- Aug 29, 2006, 17:34 UTC
- Message-ID
- <7v8xl7moo7.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <20060829162747.GA21729@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
Show 12 quoted lines
>> Shawn Pearce wrote: >> >> > From a data locality perspective putting the base object before >> > or after the delta shouldn't matter, as either way the delta >> > is useless without the base. So placing the base immediately >> > before the delta should perform just as well as placing it after. >> > Either way the OS should have the base in cache by the time the >> > delta is being accessed. >... > I'm going to shutup now and not say anything further on the subject > unless I've got some hard results indicating a different organization > is better or worse than what we have right now.
I think that may be a sensible thing to do (no sarcasm -- I think this measurement is long overdue).
The code was initially proposed just like you suggested but is in the current form precisely for the reason of avoiding back-seek. I distinctly remember me asking Linus "does mmap() favor forward scan by doing readahead? I thought its point was to allow random access" (the answer is "yes" and "yes but forward is the common case").
The pack-using side in sha1_file.c used to read deltified object (both header and delta) in full, pick up and read base, and apply delta to base. This was thought to be memory hungry on a longer delta chain, so the current code reads only the header of a deltified object, reads base, then reads the delta to apply. The last step involves seeking back, and might make the back-seek avoidance less effective than before.