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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sun Mar 19 05:24:35 2006
This archive was generated by hypermail 2.1.8 : 2006-03-19 05:24:49 EST