René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> writes: > Ever since the xdiff library had been introduced to git, all its callers > have used the flag XDF_NEED_MINIMAL. It makes sure that the smallest > possible diff is produced, but that takes quite some time if there are > lots of differences that can be expressed in multiple ways. > > This flag makes a difference for only 0.1% of the non-merge commits in > the git repo of Linux, both in terms of diff size and execution time. > The patches there are mostly nice and small. > > SungHyun Nam however reported a case in a different repo where a diff > took more than 20 times longer to generate with XDF_NEED_MINIMAL than > without. Rebasing became really slow. > > This patch removes this flag from all callers. The default of xdiff is > saner because it has minimal to no impact in the normal case of small > diffs and doesn't incur that much of a speed penalty for large ones. Thanks, will queue. > diff --git a/merge-file.c b/merge-file.c > index c336c93..db4d0d5 100644 > --- a/merge-file.c > +++ b/merge-file.c > @@ -66,7 +66,7 @@ static int generate_common_file(mmfile_t *res, mmfile_t *f1, mmfile_t *f2) > xdemitcb_t ecb; > > memset(&xpp, 0, sizeof(xpp)); > - xpp.flags = XDF_NEED_MINIMAL; > + xpp.flags = 0; > memset(&xecfg, 0, sizeof(xecfg)); > xecfg.ctxlen = 3; > xecfg.flags = XDL_EMIT_COMMON; When I wrote the message you are responding to, I tried to decide which is better, to replace the assigned value like your patch does, or to remove the assignment altogether as we have memset(&xpp, 0, sizeof(xpp)). And I was somewhat torn. While it expresses what the patch wants to do a lot clearer (and it also marks the places the "later patch" needs to touch), the resulting code becomes slightly harder to read, because future readers of the code are left with an obvious "why do we assign 0 after clearing the whole thing? is there anything subtle going on?" unanswered. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html