git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] Bump core.deltaBaseCacheLimit to 128MiB
Date: Fri, 21 Mar 2014 09:02:44 +0100	[thread overview]
Message-ID: <87ior8c72z.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <xmqqlhw5260l.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Wed, 19 Mar 2014 15:11:22 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> I know that the 512MiB default for the bitFileThreashold (aka
> "forget about delta compression") came out of thin air.  It was just
> "1GB is always too huge for anybody, so let's cut it in half and
> declare that value the initial version of a sane threashold",
> nothing more.
>
> So it might be that the problem is 512MiB is still too big, relative
> to the 16MiB of delta base cache, and the former may be what needs
> to be tweaked.

Well, the point with the 512MiB limit is basically that you can always
argue "if you are working with 500MiB files, you will not be using just
128MiB of main memory anyway".  The 16MiB limit, in contrast, will get
utilized for basically every history, even one of small files, that's
deep enough.

> If a blob close to but below 512MiB is a problem for 16MiB delta base
> cache, it would still be too big to cause the same problem for 128MiB
> delta base cache---it would evict all the other objects and then end
> up not being able to fit in the limit itself, busting the limit
> immediately, no?

I think, but may be mistaken, that the delta base limit decides when to
flush whole blobs.  So a 500MiB file would still be encoded relative to
a single newer version anyway and take memory accordingly.

But I am not sure about that at all.

-- 
David Kastrup

  parent reply	other threads:[~2014-03-21  8:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 12:38 [PATCH v2] Bump core.deltaBaseCacheLimit to 128MiB David Kastrup
2014-03-19 21:09 ` Junio C Hamano
2014-03-19 21:25   ` David Kastrup
2014-03-19 22:11     ` Junio C Hamano
2014-03-20  1:38       ` Duy Nguyen
2014-03-20 17:02         ` Junio C Hamano
2014-03-20 17:08           ` David Kastrup
2014-03-20 22:35             ` Junio C Hamano
2014-03-21  6:04               ` David Kastrup
2014-03-21  7:59                 ` Duy Nguyen
2014-03-21  8:02       ` David Kastrup [this message]
2014-03-20 23:48 ` Jeff King
2014-03-21  6:12   ` David Kastrup
2014-03-21  8:11   ` David Kastrup

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=87ior8c72z.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).