All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: David Turner <dturner@twopensource.com>,
	Duy Nguyen <pclouds@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFC] On watchman support
Date: Tue, 18 Nov 2014 20:46:00 -0500	[thread overview]
Message-ID: <20141119014600.GA2337@peff.net> (raw)
In-Reply-To: <xmqqwq6std27.fsf@gitster.dls.corp.google.com>

On Tue, Nov 18, 2014 at 01:26:56PM -0800, Junio C Hamano wrote:

> It is not check_refname_format() that is the real problem. It's the
> fact that we do O(# of refs) work whenever we have to access the
> packed-refs file. check_refname_format() is part of that, surely,
> but so is reading the file, creating all of the refname structs in
> memory, etc. (credit to peff@).

Yeah, I'd agree very much with that. I am not sure if I am cc'd here
because of my general complaining about packed-refs, or if I have said
something clever on the subject.

I did implement at one point a packed-refs reader that does a binary
search on the mmap'd packed-refs file, and can return a single value or
even locate the first entry matching a prefix (like "refs/tags/") and
iterate until we're out of the prefix. Unfortunately this runs very
contrary to the caching design of the refs.c code. It is focused on
caching _loose_ refs, where we may read an outer directory (like
"refs/"), and would like to avoid descending into an inner directory
(likes "refs/foo/") unless we are interested in what is in it. But
caching partial reads of packed-refs like this is "inside out"; we might
read all of "refs/tags/*", but have no clue what else is in "refs/". So
integrating it into refs.c would take pretty major surgery.

-Peff

  reply	other threads:[~2014-11-19  1:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-11 12:49 [RFC] On watchman support Duy Nguyen
2014-11-13  5:05 ` Torsten Bögershausen
2014-11-13 12:22   ` Duy Nguyen
2014-11-15  7:24     ` Torsten Bögershausen
2014-11-18  0:25 ` David Turner
2014-11-18 10:48   ` Duy Nguyen
2014-11-18 18:12     ` David Turner
2014-11-18 20:55       ` Junio C Hamano
2014-11-18 21:12         ` David Turner
2014-11-18 21:26           ` Junio C Hamano
2014-11-19  1:46             ` Jeff King [this message]
2014-11-28 11:13       ` Duy Nguyen
2014-12-01 20:45         ` David Turner
2014-11-19 15:26   ` Paolo Ciarrocchi
2014-11-19 16:43     ` David Turner

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=20141119014600.GA2337@peff.net \
    --to=peff@peff.net \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.