Hi, On Mon, 14 Jul 2008, Shawn O. Pearce wrote: > Nicolas Pitre <nico@xxxxxxx> 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 -- 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
