It's reasonably fast for medium sized documents. The problem is that it relies on a word-for-word LCS pass which means that the number of elements increases with (let's say a line has an average of 30 words) a factor 30 and the maximum execution time increases by 900. In Daisy this has not shown to be a problem. There are heuristics that work in constant time and in practice the LCS complexity is O(N) in stead of O(N²). Performance might still be a problem though and investigating all options in that department would be part of the project itself.

I agree that inline diffs would be nicer, instead of side-by-side.

On Sat, Mar 22, 2008 at 6:28 PM, Guy Van den Broeck <guyvdb(a)gmail.com> wrote: proposal. The impressed part I agree that inline diffs would be nicer, instead of side-by-side. Having it an HTML-rendered diff instead of a wikitext diff is useful to some extent, but it hides information. It seems like it would be relatively difficult to convey the fact that templates or images were changed, for instance, and things like comments (which must be included in diffs for proper usability) would also be an issue. Some mechanism would have to be devised to convey that such invisible changes took place. Possibly you could have an option to do a wikitext diff instead, but that doesn't seem ideal to me. Doing it one way that works well for everyone would be best if possible. As for performance, please note that Wikimedia uses a diff engine written in C++. One written in PHP would probably not be acceptable on Wikipedia, from past experience (diffing used to eat a huge amount of CPU). Scalability is also important, within reason: [[George W. Bush]] is 128 KiB, for instance.

I agree that inline diffs would be nicer, instead of side-by-side. Having it an HTML-rendered diff instead of a wikitext diff is useful to some extent, but it hides information. It seems like it would be relatively difficult to convey the fact that templates or images were changed, for instance, and things like comments (which must be included in diffs for proper usability) would also be an issue. Some mechanism would have to be devised to convey that such invisible changes took place. Possibly you could have an option to do a wikitext diff instead, but that doesn't seem ideal to me. Doing it one way that works well for everyone would be best if possible.

As for performance, please note that Wikimedia uses a diff engine written in C++. One written in PHP would probably not be acceptable on Wikipedia, from past experience (diffing used to eat a huge amount of CPU).

Roan Kattouw schreef: Not really, as one is a wikitext diff and the other a html diff. What can be used is a cached representation of the rendered html for one of the sides. Although that gives me a feeling of "something will get inconsistent here" Guy Van den Broeck, +1 to your proposal. Even if it only marked modified/added paragraphs it would be a useful addition. That is.. amazing! _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[...] The diff information (what was added/removed/changed and where) shouldn't be calculated twice, but should somehow be shared between the two. This will improve performance and increase consistency between the two diffs. It seemed to me that integrating inlinediff with wikidiff2 would be the most practical way to implement this sharing of information.

On Tue, Mar 25, 2008 at 11:20 AM, Tim Landscheidt <tim(a)tim-landscheidt.de> wrote: Yes. Otherwise nobody would have bothered rewriting the diff engine in C++. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l