diff options
author | Shawn O. Pearce <spearce@spearce.org> | 2008-07-15 04:45:34 +0000 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2008-07-15 06:37:44 -0700 |
commit | 92392b4a4530056918174988200d7c10286a4acd (patch) | |
tree | 28dadf48f67878b8aa81ceedf5cb87422e5c0267 /write_or_die.c | |
parent | index-pack: Track the object_entry that creates each base_data (diff) | |
download | tgif-92392b4a4530056918174988200d7c10286a4acd.tar.xz |
index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
If we are trying to resolve deltas for a long delta chain composed
of multi-megabyte objects we can easily run into requiring 500M+
of memory to hold each object in the chain on the call stack while
we recurse into the dependent objects and resolve them.
We now use a simple delta cache that discards objects near the
bottom of the call stack first, as they are the most least recently
used objects in this current delta chain. If we recurse out of a
chain we may find the base object is no longer available, as it was
free'd to keep memory under the deltaBaseCacheLimit. In such cases
we must unpack the base object again, which will require recursing
back to the root of the top of the delta chain as we released that
root first.
The astute reader will probably realize that we can still exceed
the delta base cache limit, but this happens only if the most
recent base plus the delta plus the inflated dependent sum up to
more than the base cache limit. Due to the way patch_delta is
currently implemented we cannot operate in less memory anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'write_or_die.c')
0 files changed, 0 insertions, 0 deletions