From: Junio C Hamano Date: Mon, 21 May 2007 04:54:53 GMT Subject: Re: [PATCH] git-pack-objects: cache small deltas between big objects Message-ID: <7v646mixnm.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <11796954641778-git-send-email-mkoegler@auto.tuwien.ac.at> Martin Koegler writes: > Creating deltas between big blobs is a CPU and memory intensive task. > In the writing phase, all (not reused) deltas are redone. > > This patch adds support for caching deltas from the deltifing phase, so > that that the writing phase is faster. > > The caching is limited to small deltas to avoid increasing memory usage very much. > The implemented limit is (memory needed to create the delta)/1024. > > Signed-off-by: Martin Koegler > --- > builtin-pack-objects.c | 35 +++++++++++++++++++++++++---------- > 1 files changed, 25 insertions(+), 10 deletions(-) This is an interesting idea. > diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c > index d165f10..13429d0 100644 > --- a/builtin-pack-objects.c > +++ b/builtin-pack-objects.c > ... > @@ -1294,10 +1302,17 @@ static int try_delta(struct unpacked *trg, struct unpacked *src, > if (!delta_buf) > return 0; > > + if (trg_entry->delta_data) > + free (trg_entry->delta_data); > + trg_entry->delta_data = 0; > trg_entry->delta = src_entry; > trg_entry->delta_size = delta_size; > trg_entry->depth = src_entry->depth + 1; > - free(delta_buf); > + /* cache delta, if objects are large enough compared to delta size */ > + if ((src_size >> 20) + (trg_size >> 21) > (delta_size >> 10)) > + trg_entry->delta_data = delta_buf; > + else > + free(delta_buf); > return 1; > } Care to justify this arithmetic? Why isn't it for example like this? ((src_size + trg_size) >> 10) > delta_size I am puzzled by the shifts on both ends, and differences between 20 and 21.