As we look at each changed file and consider breaking it, we load the blob data and make a decision about whether to break, which is independent of any other blobs that might have changed. However, we keep the data in memory while we consider breaking all of the other files. Which means that both versions of every file you are diffing are in memory at the same time. This patch instead frees the blob data as we finish with each file pair, leading to much lower memory usage. Signed-off-by: Jeff King <peff@xxxxxxxx> --- As I noted in the cover letter, this can actually slow things down slightly for some pathological cases, but I think the reduced memory consumption is worth it. I couldn't come up with a real-world case where it made any difference to the speed. One other thing where _thought_ I might cause a slowdown was in fetching the blobs for doing patch generation. But it turns out we drop the blobs already after the diffcore merge, so they weren't living that long anyway. diffcore-break.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/diffcore-break.c b/diffcore-break.c index d7097bb..15562e4 100644 --- a/diffcore-break.c +++ b/diffcore-break.c @@ -204,12 +204,16 @@ void diffcore_break(int break_score) dp->score = score; dp->broken_pair = 1; + diff_free_filespec_data(p->one); + diff_free_filespec_data(p->two); free(p); /* not diff_free_filepair(), we are * reusing one and two here. */ continue; } } + diff_free_filespec_data(p->one); + diff_free_filespec_data(p->two); diff_q(&outq, p); } free(q->queue); -- 1.6.5.2.187.g29317 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html