git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Nicolas Pitre <nico@cam.org>, Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Stephan Hennig <mailing_list@arcor.de>,
	Andreas Ericsson <ae@op5.se>
Subject: Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
Date: Tue, 15 Jul 2008 04:19:29 +0000	[thread overview]
Message-ID: <20080715041929.GC2432@spearce.org> (raw)
In-Reply-To: <m31w1wu1hc.fsf@localhost.localdomain>

Jakub Narebski <jnareb@gmail.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> 
> > > 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...
> 
> Perhaps Shawn thought here about limiting delta chain not by its
> *length*, but by its *size* (as required when unpacking last object
> in a delta chanin).
> 
> What do you think about this idea?

I was talking about that.  Or at least thinking it.  But its not a
good solution, as Dscho points out those long chains is what makes
the pack file such a powerful source code compressor.

IMHO the right solution is to continue to allow these long chains,
especially since they are typically used for the older, less often
accessed objects, and use bounded caching where necessary in the
readers to avoid unpacking costs.  We already have a bounded cache
for the random access case used by most programs.  What we missed
was the bounded cache in index-pack, and my 4 patch series is an
attempt to define that.

-- 
Shawn.

  parent reply	other threads:[~2008-07-15  4:20 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-10 14:40 git pull is slow Stephan Hennig
2008-07-10 15:13 ` Martin Langhoff
2008-07-10 15:28 ` Petr Baudis
2008-07-10 15:30 ` Johannes Sixt
2008-07-10 15:45   ` Stephan Hennig
2008-07-10 15:50     ` Petr Baudis
2008-07-10 17:44       ` Stephan Hennig
2008-07-11 12:25 ` Stephan Hennig
2008-07-11 13:34   ` Andreas Ericsson
2008-07-11 14:04     ` Johannes Schindelin
2008-07-12 12:32       ` Stephan Hennig
2008-07-12 17:05         ` Johannes Schindelin
2008-07-13  1:15           ` Shawn O. Pearce
2008-07-13 13:59             ` Johannes Schindelin
2008-07-13 22:11               ` Shawn O. Pearce
2008-07-14  2:07             ` [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack Shawn O. Pearce
2008-07-14  2:27               ` Nicolas Pitre
2008-07-14  3:12                 ` Shawn O. Pearce
2008-07-14 11:44                   ` Johannes Schindelin
2008-07-14 11:54                     ` Jakub Narebski
2008-07-14 12:10                       ` Johannes Schindelin
2008-07-14 12:16                       ` Andreas Ericsson
2008-07-14 12:25                         ` Johannes Schindelin
2008-07-14 12:51                           ` Andreas Ericsson
2008-07-14 12:58                             ` Johannes Schindelin
2008-07-15  2:21                             ` Nicolas Pitre
2008-07-15  2:47                               ` Shawn O. Pearce
2008-07-15  3:06                                 ` Nicolas Pitre
2008-07-17 16:06                                 ` Stephan Hennig
2008-07-17 16:25                                   ` Nicolas Pitre
2008-07-17 21:35                                     ` Shawn O. Pearce
2008-07-17 22:02                                       ` [RFC PATCH] index-pack: Issue a warning if deltaBaseCacheLimit is too small Shawn O. Pearce
2008-07-17 23:45                                         ` Nicolas Pitre
2008-07-15  4:19                       ` Shawn O. Pearce [this message]
2008-07-14  2:07             ` [PATCH 1/4] index-pack: Refactor base arguments of resolve_delta into a struct Shawn O. Pearce
2008-07-15  2:40               ` Nicolas Pitre
2008-07-14  2:07             ` [PATCH 2/4] index-pack: Chain the struct base_data on the stack for traversal Shawn O. Pearce
2008-07-15  2:48               ` Nicolas Pitre
2008-07-14  2:07             ` [PATCH 3/4] index-pack: Track the object_entry that creates each base_data Shawn O. Pearce
2008-07-14 10:15               ` Johannes Schindelin
2008-07-15  2:50               ` Nicolas Pitre
2008-07-15  3:20                 ` Shawn O. Pearce
2008-07-15  3:42                   ` Nicolas Pitre
2008-07-14  2:07             ` [PATCH 4/4] index-pack: Honor core.deltaBaseCacheLimit when resolving deltas Shawn O. Pearce
2008-07-15  3:05               ` Nicolas Pitre
2008-07-15  3:18                 ` Shawn O. Pearce
2008-07-15  4:45                   ` [PATCH v2] " Shawn O. Pearce
2008-07-15  5:05                     ` Nicolas Pitre
2008-07-15 18:48                     ` Junio C Hamano
2008-07-13  9:01           ` git pull is slow Stephan Hennig
2008-07-11 12:55 ` Stephan Hennig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080715041929.GC2432@spearce.org \
    --to=spearce@spearce.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=mailing_list@arcor.de \
    --cc=nico@cam.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).