[PATCH] Use adler32() from zlib instead of defining our own.

[PATCH] Use adler32() from zlib instead of defining our own.

[Peter Eriksen]

Since we already depend on zlib, we don't need to define our
own adler32().  Spotted by oprofile.

Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>


---

 diff-delta.c |   39 +--------------------------------------
 1 files changed, 1 insertions(+), 38 deletions(-)

86557e168f581f27b6869a751a56386bbc9e5059
diff --git a/diff-delta.c b/diff-delta.c
index 890986e..c2f656a 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -20,6 +20,7 @@
 
 #include <stdlib.h>
 #include "delta.h"
+#include "zlib.h"
 
 
 /* block size: min = 16, max = 64k, power of 2 */
@@ -30,44 +31,6 @@
 #define GR_PRIME 0x9e370001
 #define HASH(v, b) (((unsigned int)(v) * GR_PRIME) >> (32 - (b)))
 	
-/* largest prime smaller than 65536 */
-#define BASE 65521
-
-/* NMAX is the largest n such that 255n(n+1)/2 + (n+1)(BASE-1) <= 2^32-1 */
-#define NMAX 5552
-
-#define DO1(buf, i)  { s1 += buf[i]; s2 += s1; }
-#define DO2(buf, i)  DO1(buf, i); DO1(buf, i + 1);
-#define DO4(buf, i)  DO2(buf, i); DO2(buf, i + 2);
-#define DO8(buf, i)  DO4(buf, i); DO4(buf, i + 4);
-#define DO16(buf)    DO8(buf, 0); DO8(buf, 8);
-
-static unsigned int adler32(unsigned int adler, const unsigned char *buf, int len)
-{
-	int k;
-	unsigned int s1 = adler & 0xffff;
-	unsigned int s2 = adler >> 16;
-
-	while (len > 0) {
-		k = MIN(len, NMAX);
-		len -= k;
-		while (k >= 16) {
-			DO16(buf);
-			buf += 16;
-			k -= 16;
-		}
-		if (k != 0)
-			do {
-				s1 += *buf++;
-				s2 += s1;
-			} while (--k);
-		s1 %= BASE;
-		s2 %= BASE;
-	}
-
-	return (s2 << 16) | s1;
-}
-
 static unsigned int hashbits(unsigned int size)
 {
 	unsigned int val = 1, bits = 0;
-- 
1.1.6.g8655

Re: [PATCH] Use adler32() from zlib instead of defining our own.

[Peter Eriksen]

On Sat, Feb 04, 2006 at 11:54:01PM +0100, Peter Eriksen wrote:
> 
> Since we already depend on zlib, we don't need to define our
> own adler32().  Spotted by oprofile.

Sorry for the bad formatting, I don't use git-format-patch often enough
to be comfortable with it yet.

The patch shows no regression on my machine and at least doesn't slow
down the 2.6.15 merge with 2.6.12+change, but I don't know, if it's
correct.  It just seemed like an easy cleanup.

It was only spotted indirectly, while I was playing with OProfile
(thanks Linus), trying to find the bottlenecks in the afore mentioned 
merge.

Regards,

Peter