From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org, spearce@spearce.org
Subject: Re: RFC: Flat directory for notes, or fan-out? Both!
Date: Tue, 10 Feb 2009 17:48:20 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.1.00.0902101743180.10279@pacific.mpi-cbg.de> (raw)
In-Reply-To: <7vprhqnv0c.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 10 Feb 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> OK. I think if you are seeing performance benefits from a 2-character
> >> fanout, then we should standardize on that (do you have new performance
> >> numbers somewhere?).
> >
> > The thing is: Shawn is correct when he says that a tree object to hold the
> > notes of all commits (which is not an unlikely scenario if you are
> > thinking about corporate processes) would be huge.
> >
> >> The notes implementation is now in master. If it's about to change in an
> >> incompatible way, how do you want to handle it? I'm wary of a quick
> >> patch to change the format this late in the release cycle. We could hold
> >> it back from 1.6.2. Alternatively, we could let it release with a "this
> >> is probably going to change" warning.
> >>
> >> I think I favor holding it back, but I am not picky.
> >
> > Yes, I am also in favor of holding it back.
>
> I could do a revert on 'master' if it is really needed, but I found that
> the above reasoning is a bit troublesome. The thing is, if a tree to hold
> the notes would be huge to be unmanageable, then it would still be huge to
> be unmanageable if you split it into 256 pieces.
The thing is, a tree object of 17 megabyte is unmanagably large if you
have to read it whenever you access even a single node. Having 256 trees
instead, each of which is about 68 kilobyte is much nicer.
> I'd rather prefer to see us first try to find a way to optimze the tree
> parser. Maybe packv4 or Linus's binary search (which IIRC you declared
> would not work --- I recall I once thought about it myself but I do not
> recall what my conclusions were) play a role in it.
I declared it did not work, and showed an example here:
http://article.gmane.org/gmane.comp.version-control.git/103297
Now, this example is so concocted that it is not even funny. For example,
it falls flat down for notes, as the names never contain spaces there.
I guess that we could detect possible false positives such as my example,
by searching for NULs and spaces in the vicinity, and just search on if
there is a salmon of a doubt left.
But the worst part about it: we'd still have to unpack the whole tree
object to start bisecting (as described in said mail).
Ciao,
Dscho
next prev parent reply other threads:[~2009-02-10 16:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-09 21:12 RFC: Flat directory for notes, or fan-out? Both! Johannes Schindelin
2009-02-10 7:58 ` Boyd Stephen Smith Jr.
2009-02-10 13:16 ` Jeff King
2009-02-11 1:58 ` Boyd Stephen Smith Jr.
2009-02-11 2:35 ` Linus Torvalds
2009-02-11 3:30 ` Sam Vilain
2009-02-11 3:54 ` Linus Torvalds
2009-02-11 5:05 ` Sam Vilain
2009-02-11 12:35 ` Johannes Schindelin
2009-02-10 12:18 ` Jeff King
2009-02-10 12:59 ` Johannes Schindelin
2009-02-10 13:10 ` Jeff King
2009-02-10 13:32 ` Johannes Schindelin
2009-02-10 15:58 ` Junio C Hamano
2009-02-10 16:48 ` Shawn O. Pearce
2009-02-10 16:48 ` Johannes Schindelin [this message]
2009-02-10 16:56 ` Shawn O. Pearce
2009-02-10 17:31 ` Johannes Schindelin
2009-02-10 18:35 ` Junio C Hamano
2009-02-10 19:09 ` Shawn O. Pearce
2009-02-10 21:10 ` Johannes Schindelin
2009-02-10 22:16 ` Thomas Rast
2009-02-10 22:26 ` Thomas Rast
2009-02-10 22:32 ` Junio C Hamano
2009-02-11 20:02 ` Jeff King
2009-02-11 20:57 ` Johannes Schindelin
2009-02-11 21:16 ` Junio C Hamano
2009-02-11 23:05 ` Johannes Schindelin
2009-02-10 16:44 ` Shawn O. Pearce
2009-02-10 17:09 ` Johannes Schindelin
2009-02-10 17:17 ` Shawn O. Pearce
2009-02-11 3:19 ` Sam Vilain
2009-02-11 1:14 ` Sam Vilain
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=alpine.DEB.1.00.0902101743180.10279@pacific.mpi-cbg.de \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=spearce@spearce.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 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.