git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
	git discussion list <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] log: do not shorten decoration names too early
Date: Thu, 14 May 2015 14:10:08 -0400	[thread overview]
Message-ID: <20150514181008.GA8486@peff.net> (raw)
In-Reply-To: <xmqqzj576nts.fsf@gitster.dls.corp.google.com>

On Thu, May 14, 2015 at 11:01:03AM -0700, Junio C Hamano wrote:

> > So with your slab_peek() below, I'd guess that the slab would actually
> > be faster. But I'd also be unsurprised if it makes no appreciable
> > difference to the overall runtime of "git log --decorate". I think we'd
> > have to build it and profile (and please feel free to say "eh, not worth
> > the time to think about further").
> 
> While I think *slabname##_peek() would be worth doing regardless of
> this caller, I suspect that the major overhead of decorate code
> would come from the for_each_ref() that jumps deep into the history
> to parse old commits; it would trigger a lot of unpacking of objects
> deep in the delta chain, which would be expensive than table look-up
> in either scheme.

That would depend on the particular repository and traversal. The
expensive "load an old commit" work is done once per ref in the repo.
The lookup work is done once per commit traversed. So even if the latter
is much less work, we are typically doing it many more times, and there
is probably a balance point.

But I suspect all of it compares to the actual work of a "git log" which
has to read all of the commits we are looking at anyway. IOW, we are
probably talking about optimizing 1%, while the other 99% is spent on
inflate(), etc.

-Peff

  reply	other threads:[~2015-05-14 18:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 13:11 "HEAD -> branch" decoration doesn't work with "--decorate=full" Michael Haggerty
2015-05-13 14:51 ` Junio C Hamano
2015-05-13 15:26   ` Michael J Gruber
2015-05-13 17:11 ` Junio C Hamano
2015-05-13 17:13   ` Junio C Hamano
2015-05-13 19:40     ` [PATCH 2/2] log: do not shorten decoration names too early Junio C Hamano
2015-05-14  6:33       ` Jeff King
2015-05-14 17:37         ` Junio C Hamano
2015-05-14 17:49           ` Jeff King
2015-05-14 18:01             ` Junio C Hamano
2015-05-14 18:10               ` Jeff King [this message]
2015-05-14 21:49           ` Junio C Hamano
2015-05-14 21:54             ` Jeff King
2015-05-14 22:25               ` Junio C Hamano
2015-05-14 22:33                 ` Jeff King
2015-05-22 21:21                   ` Junio C Hamano
2015-05-22 21:38                     ` Jeff King

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=20150514181008.GA8486@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mhagger@alum.mit.edu \
    /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).