Re: [PATCH] Use diff* with --exit-code in git-am, git-rebase and git-merge-ours

Alex Riesen [off-list ref] writes:

This simplifies the shell code, reduces its memory footprint, and
speeds things up. The performance improvements should be noticable
when git-rebase works on big commits.

Thanks.

Unlike some optimizations that tilts the tradeoffs to favor
often-used case by penalizing the less often-used case, this
change does not penalize any case while optimizing some cases,
so there is nothing we are losing.  I'll take the patch for this
reason.

However, I have a few comments.

Have you run any benchmark?  I suspect "and speeds things up" is
a gross overstatement.  A qualified "SOMETIMES speeds things up"
would be a more honest thing to say.

Both of the changes to git-am are definitely good.  Under normal
usage, we expect that we would see some diff, and the optimization
applies to that normal case.

I think this does not change the performance profile in the real
life.  When the user uses the command correctly, we expect that
index and HEAD to match, and in that case the diff would take
the same amount of processing with or without --quiet.  The
change does not penalize the opposite case, so it is not a wrong
thing to do, but this is an optimization to error out early.

The first change to git-rebase optimizes the case to handle
"still to be adopted upstream" case ("upstream swallowed our
change" case would perform the same as before), so the
optimization would be more visible by people with slower
upstream and/or people patches of lessor quality that are
rejected by upstream often.  In other words, the amount of
speeding up by this change really depends on the user (there is
no slowdown for anybody so that is Ok).

The other optimizes the "erroring out early" uninteresting case.

Junio C Hamano, Sun, Mar 25, 2007 08:01:31 +0200:

However, I have a few comments.

Have you run any benchmark?  I suspect "and speeds things up" is

I didn't benchmark any of these, so I can't backup the statement with
the number but...

a gross overstatement.  A qualified "SOMETIMES speeds things up"
would be a more honest thing to say.

it must speed things up, if only for removed shell-side efforts to
redirect the output and store it in heap. To overstatement it I should
have said: "greatly speeds things up".