Re: [BUG?] Major performance issue with some commands on our repo's master branch

From: Jeff King <peff@peff.net>
Date: Jun 8, 2022, 23:36 UTC
Message-ID: <YqEyh5opAaJxph2+@coredump.intra.peff.net>
In-Reply-To: <87y1yb2xc8.fsf@gnu.org>

On Sun, Jun 05, 2022 at 12:46:15PM +0200, Tassilo Horn wrote:

> Still maybe someone might want to have a look at the "git show" issue to
> double-check if the performance burden in this specific case (no diff
> should be generated) is warranted.  But at least I can work again with
> no coffee-break long pauses, so I'm all satisfied. :-)

I suspect the issue may be quite subtle. Even you asked for "--no-patch", the underlying diff may still be used for other things. For example, simplifying away TREESAME commits. I.e., ones which did not change anything from their parents after applying path restrictions, diff-filters, etc. There may be other cases, too (e.g., --follow).

I think the code could be written to realize that none of those features are in use, and disable the diff entirely in favor of checking whether the two trees has the same object id. That would yield _mostly_ the same behavior, though there are probably corner cases (e.g., a tree with an odd mode entry, say, may get parsed so as to produce an empty diff, even though it's not byte for byte identical). That may be an acceptable tradeoff. But I think the code would be a bit brittle (it needs to know about all the cases where a diff might matter, and we may add more later).

In general, I think Git assumes that tree-level diffs aren't too painful to produce. "git log" will do them, too, but just doesn't tickle your particular case because it doesn't look at merges. So probably setting diff.renamelimit correctly is not that bad a solution.

-Peff