Bad performance with diffChars method.

[chemzqm]

It's really slow when you have lots of content remove in new string.

const fs = require('fs')
const diff =require('diff')

let arr = new Array(3000)
let content = arr.fill('a').join('\n')
let ts = Date.now()
diff.diffChars('', content)
console.log('time:' + (Date.now() - ts) + 'ms')
console.log('length:' + content.length)

Result:

time:2985ms
length:5999

[vincentracine]

I am diff'ing a 400 line XML document with a normalised alternative and the performance is poor. It takes ~5000ms to complete.

[josephrocca]

The performance of this lib seems to be quite bad compared to the diff-match-patch package. In my tests diff-match-patch is 2x to 10x faster depending on the file size (difference gets bigger as file size gets bigger), and in one instance it appears to be 20,000x faster. @kpdecker, would it be worth letting people know about the diff-match-patch package in the readme of this repo? Seems like a lot of people are using this one instead of diff-match-patch because this one has the more authorative-sounding diff name on npm, and not realising that the other package is probably better for some performance-sensitive use cases.

[v1talii-dev]

The performance of this lib seems to be quite bad compared to the diff-match-patch package. In my tests diff-match-patch is 2x to 10x faster depending on the file size (difference gets bigger as file size gets bigger), and in one instance it appears to be 20,000x faster. @kpdecker, would it be worth letting people know about the diff-match-patch package in the readme of this repo? Seems like a lot of people are using this one instead of diff-match-patch because this one has the more authorative-sounding diff name on npm, and not realising that the other package is probably better for some performance-sensitive use cases.

diff-match-patch not support html diff.

[leoswing]

Does anyone has a better performance js lib which supports html diff and fast diff both?

Much appreciated. @v1talii-dev @josephrocca

[dmsnell]

diff-match-patch is going to be faster because it relaxes the constraint that it must generate the shortest edit script. it performs additional semantic cleanups to the diff to make it more human-readable.

it's not going to give wrong results on HTML but it may not give a diff that most resembles what a person might describe manually. either way, inasmuch as diff-match-patch doesn't support HTML neither does this library or the Myers algorithm. this mostly comes into play with concurrent patches applied to the same document from different editors.

diff-match-patch is robust and fine to generate diffs for HTML unless you want an HTML-semantic diff, which again, is not provided by this library either (sadly).

[ExplodingCabbage]

The particular slow example given in this issue is now handled instantly, thanks to the optimisation in b1b2035, which will hopefully be released in a few weeks; you can try cloning the repo and building & using the code on master in the meantime. Other cases with slow performance would be interesting but to help keep track of what's still slow vs fixed, I'd like new issues opened about them if you find any!