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 <[email protected]>
---
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
