From: Jonathan Nieder <jrnieder@gmail.com>
To: Anders Kaseorg <andersk@ksplice.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
git@vger.kernel.org, "SZEDER Gábor" <szeder@ira.uka.de>,
"Kirill Smelkov" <kirr@mns.spb.ru>,
"Thomas Rast" <trast@student.ethz.ch>
Subject: Re: [PATCH] describe: Don’t look up commits with --exact-match
Date: Fri, 3 Dec 2010 02:43:48 -0600 [thread overview]
Message-ID: <20101203084348.GD18202@burratino> (raw)
In-Reply-To: <alpine.DEB.2.02.1011171830050.14285@dr-wily.mit.edu>
(+cc: completion people, who might test; Thomas, who knows this
code well)
Anders Kaseorg wrote:
> This makes ‘git describe --exact-match HEAD’ about 15 times faster on
> a cold cache (2.3s instead of 35s) in a linux-2.6 repository with many
> packed tags. That’s a huge win for the interactivity of the __git_ps1
> shell prompt helper.
Nice.
> --- a/builtin/describe.c
> +++ b/builtin/describe.c
> @@ -22,7 +22,7 @@ static int tags; /* Allow lightweight tags */
> static int longformat;
> static int abbrev = DEFAULT_ABBREV;
> static int max_candidates = 10;
> -static int found_names;
> +struct commit_name *names = NULL;
Nits:
- static?
- the convention in git is to leave off the zero-initializers
for bss-allocated vars (static and globals).
> @@ -34,6 +34,8 @@ static const char *diff_index_args[] = {
>
>
> struct commit_name {
> + struct commit_name *next;
> + unsigned char peeled[20];
> struct tag *tag;
> unsigned prio:2; /* annotated tag = 2, tag = 1, head = 0 */
> unsigned name_checked:1;
Hm, so the tags read so far will be stored in the "names" list.
> @@ -240,7 +231,12 @@ static void describe(const char *arg, int last_one)
> if (!cmit)
> die("%s is not a valid '%s' object", arg, commit_type);
>
> - n = cmit->util;
> + n = NULL;
> + for (e = names; e; e = e->next) {
> + if (hashcmp(e->peeled, cmit->object.sha1) == 0 &&
The usual convention is to use !hashcmp(...) to match the !strcmp(...)
idiom.
> + replace_name(n, e->prio, e->sha1, &e->tag))
> + n = e;
> + }
Instead of looking up the commit to be matched exactly in the commits
hash table, this makes a linear search.
No change to the assymptotic running time, but would this make things
much slower in the case of many tags? How many before it's a problem
(if ever)? (If it's a problem in ordinary cases, I think the
optimization could be limited to --exact-match pretty easily.)
> @@ -259,6 +255,12 @@ static void describe(const char *arg, int last_one)
> if (debug)
> fprintf(stderr, "searching to describe %s\n", arg);
>
> + for (e = names; e; e = e->next) {
> + struct commit *c = lookup_commit_reference_gently(e->peeled, 1);
> + if (c && replace_name(c->util, e->prio, e->sha1, &e->tag))
> + c->util = e;
> + }
Filling the commits table in preparation for object traversal. Now
the world's back to normal.
> @@ -418,8 +420,8 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
> return cmd_name_rev(i + argc, args, prefix);
> }
>
> - for_each_ref(get_name, NULL);
> + for_each_rawref(get_name, NULL);
Orthogonal change snuck in?
> - if (!found_names && !always)
> + if (!names && !always)
Everything else looks good and very readable.
next prev parent reply other threads:[~2010-12-03 8:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 23:33 [PATCH] describe: Don’t look up commits with --exact-match Anders Kaseorg
2010-12-03 8:43 ` Jonathan Nieder [this message]
2010-12-06 7:19 ` Anders Kaseorg
2010-12-06 7:22 ` Anders Kaseorg
2010-12-06 7:32 ` Jonathan Nieder
2010-12-06 10:53 ` Thomas Rast
2010-12-06 17:28 ` Anders Kaseorg
2010-12-06 17:47 ` Jonathan Nieder
2010-12-07 9:58 ` SZEDER Gábor
2010-12-07 18:22 ` [PATCH 1/2] describe: Use for_each_rawref Anders Kaseorg
2010-12-07 18:22 ` [PATCH 2/2] describe: Don’t look up commits with --exact-match Anders Kaseorg
2010-12-07 18:26 ` [PATCH 1/2] describe: Use for_each_rawref Anders Kaseorg
2010-12-07 19:49 ` Junio C Hamano
2010-12-07 21:59 ` Junio C Hamano
2010-12-07 18:39 ` [PATCH] describe: Don’t look up commits with --exact-match Junio C Hamano
2010-12-08 4:41 ` Anders Kaseorg
2010-12-08 4:42 ` [PATCH v2 1/4] describe: Use for_each_rawref Anders Kaseorg
2010-12-08 4:43 ` [PATCH v2 2/4] describe: Don’t use a flex array in struct commit_name Anders Kaseorg
2010-12-08 4:43 ` [PATCH v2 3/4] describe: Store commit_names in a hash table by commit SHA1 Anders Kaseorg
2010-12-08 18:23 ` [PATCH v2.1 " Anders Kaseorg
2010-12-08 22:50 ` Junio C Hamano
2010-12-08 4:46 ` [PATCH v2 4/4] describe: Delay looking up commits until searching for an inexact match Anders Kaseorg
2010-12-08 22:50 ` Junio C Hamano
2010-12-08 23:47 ` Anders Kaseorg
2010-12-09 6:42 ` [PATCH v3 1/4] describe: Use for_each_rawref Anders Kaseorg
2010-12-09 6:43 ` [PATCH v3 2/4] describe: Don’t use a flex array in struct commit_name Anders Kaseorg
2010-12-09 6:46 ` [PATCH v3 3/4] describe: Store commit_names in a hash table by commit SHA1 Anders Kaseorg
2010-12-09 6:47 ` [PATCH v3 4/4] describe: Delay looking up commits until searching for an inexact match Anders Kaseorg
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=20101203084348.GD18202@burratino \
--to=jrnieder@gmail.com \
--cc=andersk@ksplice.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kirr@mns.spb.ru \
--cc=szeder@ira.uka.de \
--cc=trast@student.ethz.ch \
/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).