Michael Haggerty <mhag...@alum.mit.edu> writes:

> The condition under which gc_boundary() is called was previously
>
>     if (alloc <= nr)
>
> .  But by construction, nr can never exceed alloc, so the check looks
> unnecessarily mysterious.  In fact, the purpose of the check is to try
> to avoid a realloc() call by shrinking the array if possible if it is
> at its allocation limit when a new element is about to be added.  So
> change the check to
>
>     if (nr == alloc)
>
> and add a comment to explain what's going on.
>
> Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
> ---
> Please check that I have properly described the purpose of this check.
>
> The way the code is written, it looks like a bad pattern of growth and
> shrinkage of the array (namely, just under the resize limit) could
> cause gc_boundary() to be called over and over again with (most of)
> the same data.  I hope that the author had some reason to believe that
> such a pattern is unlikely.

That is about comparing with "alloc", not having high and low
watermarks, right?

I do not see "alloc <= nr" is mysterious at all; it is merely being
defensive.

>
>  revision.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/revision.c b/revision.c
> index 2e0992b..19c59f4 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2573,8 +2573,10 @@ static struct commit *get_revision_internal(struct 
> rev_info *revs)
>               if (p->flags & (CHILD_SHOWN | SHOWN))
>                       continue;
>               p->flags |= CHILD_SHOWN;
> -             if (revs->boundary_commits.alloc <= revs->boundary_commits.nr)
> +             if (revs->boundary_commits.nr == revs->boundary_commits.alloc) {
> +                     /* Try to make space and thereby avoid a realloc(): */
>                       gc_boundary(&revs->boundary_commits);
> +             }
>               add_object_array(p, NULL, &revs->boundary_commits);
>       }
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to