Jeff King <peff@xxxxxxxx> writes: > This is a nice incremental step in the sense that people can still > enable it if they want to in order to time it, play with it, etc. But > given what we know, I wonder if the help text here should warn people. > > Or I guess we could move straight to dropping it entirely. > > Here's what that patch might look like (I retimed it just be sure, and > was sad to see that it really _is_ making some cases faster. But I still > think slower-but-predictable is a better default). I like this version that drops quite a lot of code ;-) > Subject: [PATCH] xdiff: drop XDL_FAST_HASH > ... > The idea of XDL_FAST_HASH is to speed up the hash > computation. But the generated hashes have worse collision > behavior. This means that in some cases it speeds diffs up > (running "git log -p" on git.git improves by ~8% with it), > but in others it can slow things down. One pathological case > saw over a 100x slowdown[1]. > > There may be a better hash function that covers both > properties, but in the meantime we are better off with the > original hash. It's slightly slower in the common case, but > it has fewer surprising pathological cases. > > [1] http://public-inbox.org/git/20141222041944.GA441@xxxxxxxx/