On Fri, 17 Mar 2006, Junio C Hamano wrote: > Once you make it into a patch form, it is plainly obvious that > this is a good optimization. Since our BLK_SIZE is 16 bytes, > you are grabbing up to 15 more bytes (on average 8 more bytes or > so) for every match after a partially modified block. > > Very nice. I wonder if a larger BLK_SIZE (say 32 bytes) would > give us faster packing without losing much compression if we use > this idea. Tried that long ago. As BLK_SIZE is increased the adler32 cost, which has to be computed for every offset in the target buffer, increases accordingly. So you end up with both worse compression and more CPU usage. Nicolas - : 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