summaryrefslogtreecommitdiff
path: root/write_or_die.c
diff options
context:
space:
mode:
authorLibravatar Shawn O. Pearce <spearce@spearce.org>2008-07-15 04:45:34 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2008-07-15 06:37:44 -0700
commit92392b4a4530056918174988200d7c10286a4acd (patch)
tree28dadf48f67878b8aa81ceedf5cb87422e5c0267 /write_or_die.c
parentindex-pack: Track the object_entry that creates each base_data (diff)
downloadtgif-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