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

From: Jeff King <peff@peff.net>
Date: Jun 9, 2022, 18:43 UTC
Message-ID: <YqI/TcZyXomxtXtN@coredump.intra.peff.net>
In-Reply-To: <xmqqedzxlmpt.fsf@gitster.g>

On Thu, Jun 09, 2022 at 11:23:58AM -0700, Junio C Hamano wrote:

Show 9 quoted lines

> > I think you'd do better to have a mode specific to git-show that skips
> > the diff if we're not showing it, but makes sure to always show the
> > commit anyway.
> 
> Meaning an explicit option "git show --log-only"?  We'd need to
> careful to make it either (1) be incompatible with certain features
> of "git show" (like giving a pathspec) and error out, or (2) ignore
> these features of "git show" silently and document that.  But it
> would work as a new option.

Certainly a new option would mean we weren't regressing any existing behavior. I do think it would be a hard option to explain, though.

But what I wondered is whether "show" in particular, because it would never want to skip showing a commit, could get away with avoiding the diff automatically. I.e., currently "git show -Sfoo HEAD" will always show HEAD, even if "-S" does not match anything. So if we are not showing any diff output, there is no need to compute the diff in that case. That is unlike "git log", which would omit commits that didn't match.

And really it is not "git show" that is special there, but the always_show_header flag it sets. So something like this might work:

diff --git a/log-tree.c b/log-tree.c
index d0ac0a6327..ed57386938 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -1024,6 +1024,10 @@ static int log_tree_diff(struct rev_info *opt, struct commit *commit, struct log
 	if (!all_need_diff && !opt->merges_need_diff)
 		return 0;
 
+	if (opt->diffopt.output_format == DIFF_FORMAT_NO_OUTPUT &&
+	    opt->always_show_header)
+		return 0;
+
 	parse_commit_or_die(commit);
 	oid = get_commit_tree_oid(commit);
 

It produces the same output in the cases I tried. And running with
GIT_TRACE2_PERF shows that it doesn't diff and rename code.

I'm not overly confident that it isn't violating some other subtle
assumption / corner case that I haven't thought of, though. :)

-Peff