git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/7] diffcore-rename: remove unnecessary if-clause

From
Elijah Newren <newren@gmail.com>
Date
Dec 10, 2020, 00:32 UTC
Message-ID
<CABPp-BHQNy3MQ9u=sZKd0h2vqOzhFZC35XqR-QbHgzeiJ7VbLQ@mail.gmail.com>
In-Reply-To
<X9FLaiuWpYely6es@nand.local>
On Wed, Dec 9, 2020 at 2:10 PM Taylor Blau <me@ttaylorr.com> wrote:
Show 54 quoted lines
>
> On Sun, Dec 06, 2020 at 02:54:31AM +0000, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@gmail.com>
> >
> > diffcore-rename had two different checks of the form
> >
> >     if ((a < limit || b < limit) &&
> >         a * b <= limit * limit)
> >
> > Since these are all non-negative integers, this can be simplified to
> >
> >     if (a * b <= limit * limit)
>
> Makes sense.
>
> > The only advantage of the former would be in avoiding a couple
> > multiplications in the rare case that both a and b are BOTH very large.
> > I see no reason for such an optimization given that this code is not in
> > any kind of loop.  Prefer code simplicity here and change to the latter
> > form.
>
> If you were really paranoid, you could perform these checks with
> unsigned_mult_overflows(), but I don't think that it's worth doing so
> here.
>
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> >  diffcore-rename.c | 10 ++++------
> >  1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/diffcore-rename.c b/diffcore-rename.c
> > index 68ddf51a2a1..0f8fce9293e 100644
> > --- a/diffcore-rename.c
> > +++ b/diffcore-rename.c
> > @@ -450,9 +450,8 @@ static int too_many_rename_candidates(int num_targets, int num_sources,
> >        */
> >       if (rename_limit <= 0)
> >               rename_limit = 32767;
> > -     if ((num_targets <= rename_limit || num_sources <= rename_limit) &&
> > -         ((uint64_t)num_targets * (uint64_t)num_sources
> > -          <= (uint64_t)rename_limit * (uint64_t)rename_limit))
> > +     if ((uint64_t)num_targets * (uint64_t)num_sources
> > +         <= (uint64_t)rename_limit * (uint64_t)rename_limit)
>
> One small nit here (and below) is that not all of these need casting.
> Only one operand of each multiplication needs to be widened for the
> compiler to widen the other, too. So, I'd write this instead as:
>
> > +     if ((num_targets * (uint64_t)num_sources) <=
> > +     (rename_limit * (uint64_t)rename_limit))
>
> or something. (I tend to prefer the cast on the right-most operand,
> since it makes clear that there's no need to cast the "first" operand,
> and that casting either will do the trick).

Yeah, I think that reads slightly better too, but on the other hand it does make the diff slightly harder to read. *shrug*.

Show 16 quoted lines
> >               return 0;
> >
> >       options->needed_rename_limit =
> > @@ -468,9 +467,8 @@ static int too_many_rename_candidates(int num_targets, int num_sources,
> >                       continue;
> >               limited_sources++;
> >       }
> > -     if ((num_targets <= rename_limit || limited_sources <= rename_limit) &&
> > -         ((uint64_t)num_targets * (uint64_t)limited_sources
> > -          <= (uint64_t)rename_limit * (uint64_t)rename_limit))
> > +     if ((uint64_t)num_targets * (uint64_t)limited_sources
> > +         <= (uint64_t)rename_limit * (uint64_t)rename_limit)
>
> Same notes here, of course. I was hoping that we could only do this
> multiplication once, but it looks like limited_sources grows between the
> two checks, so we have to repeat it here, I suppose.

The right hand side of the expression is the same -- rename_limit * rename_limit -- so it could be stored off (though I don't think there's much point in doing so unless it made the code clearer; this is not remotely close to a hot path). However, in the left hand side, it's not so much that one of the variables has changed since the last check, it's that it uses a different set of variables in the check. In particular, it replaces 'num_sources' with 'limited_sources'.

Previous: Taylor BlauNext: Junio C Hamano
Message 6 of 55 in “diffcore-rename improvements”
  1. 0/7 diffcore-rename improvementsElijah Newren via GitGitGadget, Dec 6, 2020
  2. 4/7 diffcore-rename: change a few comments to use 'add' instead of 'create'Elijah Newren via GitGitGadget, Dec 6, 2020
  3. Junio C HamanoDec 10, 2020
  4. 2/7 diffcore-rename: remove unnecessary if-clauseElijah Newren via GitGitGadget, Dec 6, 2020
  5. Taylor BlauDec 9, 2020
  6. Elijah NewrenDec 10, 2020
  7. Junio C HamanoDec 10, 2020
  8. Elijah NewrenDec 10, 2020
  9. Junio C HamanoDec 10, 2020
  10. Elijah NewrenDec 6, 2020
  11. 7/7 Accelerate rename_dst setupElijah Newren via GitGitGadget, Dec 6, 2020
  12. Taylor BlauDec 9, 2020
  13. Elijah NewrenDec 10, 2020
  14. Junio C HamanoDec 10, 2020
  15. 6/7 diffcore-rename: simplify and accelerate register_rename_src()Elijah Newren via GitGitGadget, Dec 6, 2020
  16. Taylor BlauDec 9, 2020
  17. Elijah NewrenDec 10, 2020
  18. Taylor BlauDec 10, 2020
  19. Junio C HamanoDec 10, 2020
  20. 5/7 diffcore-rename: reduce jumpiness in progress countersElijah Newren via GitGitGadget, Dec 6, 2020
  21. Taylor BlauDec 9, 2020
  22. Junio C HamanoDec 10, 2020
  23. 3/7 diffcore-rename: rename num_create to num_targetsElijah Newren via GitGitGadget, Dec 6, 2020
  24. Junio C HamanoDec 10, 2020
  25. Elijah NewrenDec 10, 2020
  26. 1/7 diffcore-rename: avoid usage of global in too_many_rename_candidates()Elijah Newren via GitGitGadget, Dec 6, 2020
  27. Taylor BlauDec 9, 2020
  28. 0/9 diffcore-rename improvementsElijah Newren via GitGitGadget, Dec 11, 2020
  29. 1/9 diffcore-rename: rename num_create to num_destinationsElijah Newren via GitGitGadget, Dec 11, 2020
  30. 2/9 diffcore-rename: avoid usage of global in too_many_rename_candidates()Elijah Newren via GitGitGadget, Dec 11, 2020
  31. 3/9 diffcore-rename: simplify limit checkElijah Newren via GitGitGadget, Dec 11, 2020
  32. 8/9 diffcore-rename: accelerate rename_dst setupElijah Newren via GitGitGadget, Dec 11, 2020
  33. 7/9 diffcore-rename: simplify and accelerate register_rename_src()Elijah Newren via GitGitGadget, Dec 11, 2020
  34. 4/9 diffcore-rename: reduce jumpiness in progress countersElijah Newren via GitGitGadget, Dec 11, 2020
  35. 9/9 diffcore-rename: remove unneccessary duplicate entry checksElijah Newren via GitGitGadget, Dec 11, 2020
  36. Christian CouderDec 29, 2020
  37. Elijah NewrenDec 29, 2020
  38. 5/9 t4058: add more tests and documentation for duplicate tree entry handlingElijah Newren via GitGitGadget, Dec 11, 2020
  39. 6/9 t4058: explore duplicate tree entry handling in a bit more detailElijah Newren via GitGitGadget, Dec 11, 2020
  40. Ævar Arnfjörð BjarmasonApr 21, 2021
  41. Elijah NewrenApr 21, 2021
  42. 0/9 diffcore-rename improvementsElijah Newren via GitGitGadget, Dec 29, 2020
  43. 1/9 diffcore-rename: rename num_create to num_destinationsElijah Newren via GitGitGadget, Dec 29, 2020
  44. 8/9 diffcore-rename: accelerate rename_dst setupElijah Newren via GitGitGadget, Dec 29, 2020
  45. 7/9 diffcore-rename: simplify and accelerate register_rename_src()Elijah Newren via GitGitGadget, Dec 29, 2020
  46. 2/9 diffcore-rename: avoid usage of global in too_many_rename_candidates()Elijah Newren via GitGitGadget, Dec 29, 2020
  47. 3/9 diffcore-rename: simplify limit checkElijah Newren via GitGitGadget, Dec 29, 2020
  48. Başar UğurNov 9, 2021
  49. Elijah NewrenNov 10, 2021
  50. Başar UğurNov 11, 2021
  51. Elijah NewrenNov 11, 2021
  52. 4/9 diffcore-rename: reduce jumpiness in progress countersElijah Newren via GitGitGadget, Dec 29, 2020
  53. 9/9 diffcore-rename: remove unnecessary duplicate entry checksElijah Newren via GitGitGadget, Dec 29, 2020
  54. 6/9 t4058: explore duplicate tree entry handling in a bit more detailElijah Newren via GitGitGadget, Dec 29, 2020
  55. 5/9 t4058: add more tests and documentation for duplicate tree entry handlingElijah Newren via GitGitGadget, Dec 29, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.