Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jul 14, 2008, 11:44 UTC
- Message-ID
- <alpine.LSU.1.00.0807141216390.32392@wbgn129.biozentrum.uni-wuerzburg.de>
- In-Reply-To
- <20080714031242.GA14542@spearce.org>
Hi,
On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
Show 19 quoted lines
> Nicolas Pitre <nico@cam.org> wrote: > > On Sun, 13 Jul 2008, Shawn O. Pearce wrote: > > > > > This should resolve the obscene memory usage of index-pack when > > > resolving deltas for very large files. > > > > I don't like this. Not your patch, but rather the direction this whole > > thing took in the first place, and now we have to bolt extra complexity > > on top. > > > > I have the feeling this is not the best approach, especially since many > > long delta chains are going deep and all those intermediate objects are > > simply useless once the _only_ delta child has been resolved and > > therefore could be freed right away instead. > > I thought about trying to free a base object if this is the last > resolve_delta() call which would require that data, but I realized this > is just a "tail-call optimization" and doesn't work in the more general > case.
However, for cases like Stephan's I assume this is the rule. If you think of it, most use cases for such a big blob are one-user, append-only.
> The only other alternative I can come up with is to change pack-objects > (or at least its defaults) so we don't generate these massive delta > chains. But there are already packs in the wild that use these chains, > resulting in performance problems for clients.
But the long chains make the pack actually as efficient as it is...
Ciao, Dscho