Re: "git notes show" is orders of magnitude slower than doing it manually with ls-tree and cat-file
- From
Mike Hommey <mh@glandium.org>
- Date
- Nov 26, 2014, 02:30 UTC
- Message-ID
- <20141126023039.GA19401@glandium.org>
- In-Reply-To
- <20141126013456.GA13622@peff.net>
On Tue, Nov 25, 2014 at 08:34:57PM -0500, Jeff King wrote:
Show 21 quoted lines
> On Tue, Nov 25, 2014 at 08:24:48PM -0500, Jeff King wrote:
>
> > However, this is not what trees created by git-notes look like. It
> > shards the object sha1s into subtrees (1a/2b/{36}), and I think does so
> > dynamically in a way that keeps each individual tree size low. The
> > in-memory data structure then only "faults in" tree objects as they are
> > needed. So a single lookup should only hit a small part of the total
> > tree.
> >
> > Doing a single "git notes edit HEAD" in my case caused the notes code to
> > write the result using its sharding algorithm. Subsequent "git notes
> > show" invocations were only 14ms.
> >
> > Did you use something besides git-notes to create the tree? From your
> > examples, it looks like you were accounting for the sharding during
> > lookup, so maybe this is leading in the wrong direction (but if so, I
> > could not reproduce your times at all even with a much larger case).
>
> Hmph. Having just written all that, I looked at your example again, and
> you are running "git ls-tree -r", which would read the whole tree
> anyway. So "git notes" should be _faster_ for a single lookup.The -r actually doesn't matter, since what's being listed is a blob, not a tree, so there is no recursion.
Mike