You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sander Striker <st...@apache.org> on 2003/01/10 23:06:36 UTC
More diff lib stuff
Hi,
I'm progressing fairly well with implementing diff3
merged output with conflict markers.
$ ./diff3 original modified latest
a
c
e
b
d
e
<<<< MODIFIED
b
b
a
==== LATEST
g
g
f
>>>> END
c
b
e
<<<< MODIFIED
x
==== LATEST
y
>>>> END
Compare this to:
$ diff3 -m original modified latest
a
c
b
d
e
a
<<<<<<< original
c
||||||| modified
b
b
a
=======
g
g
f
>>>>>>> latest
b
e
d
<<<<<<< original
||||||| modified
x
=======
y
>>>>>>> latest
Which is pretty neat. I need to clean up some of this
code before committing though. Sorry about that.
Ofcourse, while working on this I stumbled over the
current implementation of diff... *blush* I remember
now that to get something working I used md5 hashes
of each line... No wonder we perform bad on 6MB files
(still only 3.5 seconds with a _lot_ of differences
and matches).
Secondly we can just pull the file into memory directly
instead of processing chunks of 4k at a time... Twice.
Anyhow, after I tackle the diff3 output those bottlenecks
are the first to go. It would be very nice if we could
come close to GNU diff performance (which I think we
can).
Bear with me...
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: More diff lib stuff
Posted by mark benedetto king <mb...@earthquake.boredom.org>.
Sat, Jan 11, 2003 at 12:06:36AM +0100, Sander Striker wrote:
> Ofcourse, while working on this I stumbled over the
> current implementation of diff... *blush* I remember
> now that to get something working I used md5 hashes
> of each line... No wonder we perform bad on 6MB files
> (still only 3.5 seconds with a _lot_ of differences
> and matches).
>
Would Adler-32 be more appropriate?
/*
* An Adler-32 implementation per RFC1950.
*
* "The Adler-32 algorithm is much faster than the CRC32 algorithm yet
* still provides an extremely low probability of undetected errors"
*/
#include <stdio.h>
#include <sys/types.h>
/*
* 65521 is the largest prime less than 65536.
* "That 65521 is prime is important to avoid a possible large class of
* two-byte errors that leave the check unchanged."
*/
#define MOD_BASE 65521
/*
* "The modulo on unsigned long accumulators can be delayed for 5552 bytes,
* so the modulo operation time is negligible."
*/
#define MOD_BLOCK_SIZE 5552
u_int32_t
adler32_update(u_int32_t checksum,
const unsigned char *input,
size_t length)
{
u_int32_t s1 = checksum & 0xFFFF;
u_int32_t s2 = checksum >> 16;
size_t blocks = length / MOD_BLOCK_SIZE;
length %= MOD_BLOCK_SIZE;
while (blocks--)
{
int count = MOD_BLOCK_SIZE;
while (count--)
{
u_int32_t b = *input++;
s1 += b;
s2 += s1;
}
s1 %= MOD_BASE;
s2 %= MOD_BASE;
}
while (length--)
{
u_int32_t b = *input++;
s1 += b;
s2 += s1;
}
return ((s2 % MOD_BASE) << 16) |
(s1 % MOD_BASE);
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org