[PATCH 10/17] get_revision_internal(): make check less mysterious

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: May 19, 2013, 20:27 UTC
Message-ID: <1368995232-11042-11-git-send-email-mhagger@alum.mit.edu>
In-Reply-To: <1368995232-11042-1-git-send-email-mhagger@alum.mit.edu>

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 <mhagger@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.

 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);
 	}

-- 
1.8.2.3