When c6458e60 (index-pack: kill union delta_base to save memory,
2015-04-18) attempted to reduce the memory footprint of index-pack,
one of the key thing it did was to keep track of ref-deltas and
ofs-deltas separately.

In fix_unresolved_deltas(), however it forgot that it now wants to
look only at ref deltas in one place.  The code allocated an array
sufficient to hold both ref- and ofs-deltas, stuffed only ref-deltas
in the array, sorted it (with the right count) and iterated over the
array (with the right count).

There is no externally visible ill effect, other than a small
wastage of memory, but the code was misleading.

Also, the old code before this change had to use 'i' and 'n' because
some of the things we see in the (old) deltas[] array we scanned
with 'i' would not make it into the sorted_by_pos[] array in the old
world order, but now because you have only ref delta in a separate
ref_deltas[] array, they increment lock&step.  We no longer need
separate variables (nor the nr_unresolved parameter).

Helped-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
Signed-off-by: Junio C Hamano <gits...@pobox.com>
---

 * This time with a formal log message.  Again, this is not really a
   "bug"-fix; just returning the memory that we allocated without
   using to the system, and making the code easier to follow.

 builtin/index-pack.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 3ed53e3..fa13e20 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1223,7 +1223,7 @@ static void resolve_deltas(void)
  * - append objects to convert thin pack to full pack if required
  * - write the final 20-byte SHA-1
  */
-static void fix_unresolved_deltas(struct sha1file *f, int nr_unresolved);
+static void fix_unresolved_deltas(struct sha1file *f);
 static void conclude_pack(int fix_thin_pack, const char *curr_pack, unsigned 
char *pack_sha1)
 {
        if (nr_ref_deltas + nr_ofs_deltas == nr_resolved_deltas) {
@@ -1245,7 +1245,7 @@ static void conclude_pack(int fix_thin_pack, const char 
*curr_pack, unsigned cha
                memset(objects + nr_objects + 1, 0,
                       nr_unresolved * sizeof(*objects));
                f = sha1fd(output_fd, curr_pack);
-               fix_unresolved_deltas(f, nr_unresolved);
+               fix_unresolved_deltas(f);
                strbuf_addf(&msg, _("completed with %d local objects"),
                            nr_objects - nr_objects_initial);
                stop_progress_msg(&progress, msg.buf);
@@ -1328,10 +1328,10 @@ static int delta_pos_compare(const void *_a, const void 
*_b)
        return a->obj_no - b->obj_no;
 }
 
-static void fix_unresolved_deltas(struct sha1file *f, int nr_unresolved)
+static void fix_unresolved_deltas(struct sha1file *f)
 {
        struct ref_delta_entry **sorted_by_pos;
-       int i, n = 0;
+       int i;
 
        /*
         * Since many unresolved deltas may well be themselves base objects
@@ -1343,12 +1343,12 @@ static void fix_unresolved_deltas(struct sha1file *f, 
int nr_unresolved)
         * before deltas depending on them, a good heuristic is to start
         * resolving deltas in the same order as their position in the pack.
         */
-       sorted_by_pos = xmalloc(nr_unresolved * sizeof(*sorted_by_pos));
+       sorted_by_pos = xmalloc(nr_ref_deltas * sizeof(*sorted_by_pos));
        for (i = 0; i < nr_ref_deltas; i++)
-               sorted_by_pos[n++] = &ref_deltas[i];
-       qsort(sorted_by_pos, n, sizeof(*sorted_by_pos), delta_pos_compare);
+               sorted_by_pos[i] = &ref_deltas[i];
+       qsort(sorted_by_pos, nr_ref_deltas, sizeof(*sorted_by_pos), 
delta_pos_compare);
 
-       for (i = 0; i < n; i++) {
+       for (i = 0; i < nr_ref_deltas; i++) {
                struct ref_delta_entry *d = sorted_by_pos[i];
                enum object_type type;
                struct base_data *base_obj = alloc_base_data();
-- 
2.5.0-rc1-213-g8b7a1c9

--
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