On Tue, 29 Aug 2006, Shawn Pearce wrote: > Sorry but this really is a pretty stupid question on my part: > > In builtin-pack-objects.c write_one(), why is the base object written > behind the first delta that depends on it (if it hasn't been written > already) rather than BEFORE the first delta that depends on it? Most of the time the base object will have been written already since we favor backward deltas, and newer objects are written first. But that might not always be the case. > If the base always had to appear before any delta that uses it then > unpack-objects wouldn't need to cache a delta in memory waiting > for the base to get unpacked. Like mentioned above this is not the common case. And deltas are small anyway. And when you think about it the delta and base objects have to be both in memory so this doesn't change anything in the end. So in practice there is no really special caching. > >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. Not necessarily. In fact if you checkout a particular revision with such a case, putting the base first will force a seek over it since what is referenced first is the delta, then seek back to the base. If it is right after the delta then there is no need to seek back and some read ahead might have picked the base by the time it is referenced. OK since all this is mmap()'ed there might not be much difference in practice, but in theory the current arrangement could have a slight advantage. > In other words, why not apply this patch and make it a requirement > of the pack file format? I don't think this should be a requirement. Nicolas - 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