Thread (5 messages) flat view 5 messages, 1 author, 2016-06-15

Serious performance regression in diff between 1.6.6 and 1.7.0

From: Brian Downing <hidden>
Date: 2016-06-15 22:48:56

I've stumbled across a pretty serious performance regression in "git
diff" for a large (187456 files checked out on HEAD) repository of mine.

I bisected it and the first slow commit is:
commit 730f72840cc50c523fe4cdd796ea2d2fc4571a28
Author: Junio C Hamano [off-list ref]
Date:   Sun Sep 20 00:03:39 2009 -0700

    unpack-trees.c: look ahead in the index

    This makes the traversal of index be in sync with the tree traversal.
    When unpack_callback() is fed a set of tree entries from trees, it
    inspects the name of the entry and checks if the an index entry with
    the same name could be hiding behind the current index entry, and

    ...

It is more than 10x worse for my case here:

before 730f72840cc50c523fe4cdd796ea2d2fc4571a28:
:; /usr/bin/time ~/src/git/git-diff HEAD >/dev/null
0.30user 0.50system 0:00.81elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+30119minor)pagefaults 0swaps

730f72840cc50c523fe4cdd796ea2d2fc4571a28:
:; /usr/bin/time ~/src/git/git-diff HEAD >/dev/null
5.58user 0.40system 0:05.98elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+30117minor)pagefaults 0swaps

Unfortunately this pushes everyday use past my pain threshold for this
repository.  (As a sidenote, it's amazing how much Git has adjusted my
pain threshold since the days of CVS!)

Is there any chance of algorithmic improvements to this fix to gain some
of this speed back, or am I stuck with this when using newer Git?

-bcd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help