Martin Koegler <mkoegler@xxxxxxxxxxxxxxxxx> 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 <mkoegler@xxxxxxxxxxxxxxxxx> > --- > 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. - 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
