git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: John Cai via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, John Cai <johncai86@gmail.com>
Subject: Re: [PATCH] cat-file: skip expanding default format
Date: Mon, 07 Mar 2022 13:15:48 +0100	[thread overview]
Message-ID: <220307.865yoq0x7e.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <pull.1221.git.git.1646429845306.gitgitgadget@gmail.com>


On Fri, Mar 04 2022, John Cai via GitGitGadget wrote:

> From: John Cai <johncai86@gmail.com>
>
> When format is passed into --batch, --batch-check, --batch-command,
> the format gets expanded. When nothing is passed in, the default format
> is set and the expand_format() gets called.
>
> We can save on these cycles by hardcoding how to print the
> information when nothing is passed as the format, or when the default
> format is passed. There is no need for the fully expanded format with
> the default. Since batch_object_write() happens on every object provided
> in batch mode, we get a nice performance improvement.
>
> git rev-list --all > /tmp/all-obj.txt
>
> git cat-file --batch-check </tmp/all-obj.txt
>
> with HEAD^:
>
> Time (mean ± σ): 57.6 ms ± 1.7 ms [User: 51.5 ms, System: 6.2 ms]
> Range (min … max): 54.6 ms … 64.7 ms 50 runs
>
> with HEAD:
>
> Time (mean ± σ): 49.8 ms ± 1.7 ms [User: 42.6 ms, System: 7.3 ms]
> Range (min … max): 46.9 ms … 55.9 ms 56 runs
>
> If nothing is provided as a format argument, or if the default format is
> passed, skip expanding of the format and print the object info with a
> default format.
>
> Based-on-patch-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

Nit: I think it's probably better to just add a Signed-off-by here for
me instead to indicate that it's originally based on my crappy WIP code
(but most of what you've got here is thoroughly yours & better).

> Signed-off-by: John Cai <johncai86@gmail.com>
> [...]
> +static void print_default_format(char *buf, int len, struct expand_data *data)
> +{
> +	snprintf(buf, len, "%s %s %"PRIuMAX"\n", oid_to_hex(&data->oid),
> +		 data->info.type_name->buf,
> +		 (uintmax_t)*data->info.sizep);
> +
> +}
> +
>  /*
>   * If "pack" is non-NULL, then "offset" is the byte offset within the pack from
>   * which the object may be accessed (though note that we may also rely on
> @@ -363,6 +372,12 @@ static void batch_object_write(const char *obj_name,
>  			       struct packed_git *pack,
>  			       off_t offset)
>  {
> +	const char *fmt;
> +
> +	struct strbuf type_name = STRBUF_INIT;
> +	if (!opt->format)
> +		data->info.type_name = &type_name;
> +
>  	if (!data->skip_object_info) {
>  		int ret;
>  
> @@ -377,12 +392,21 @@ static void batch_object_write(const char *obj_name,
>  			printf("%s missing\n",
>  			       obj_name ? obj_name : oid_to_hex(&data->oid));
>  			fflush(stdout);
> -			return;
> +			goto cleanup;
>  		}
>  	}
>  
> +	if (!opt->format && !opt->print_contents) {
> +		char buf[1024];
> +
> +		print_default_format(buf, 1024, data);
> +		batch_write(opt, buf, strlen(buf));

Just a nit (Junio comment on most of the rest), for something that's an
optimization patch we shouldn't ever need to do strlen() here, since we
just called snprintf(), let's just use its return value instead.

I also think that in this case you'll want xsnprintf(), and if not this
code is buggy & needs to check the return value (but let's just use x*()
...).

FWIW snprintf() relly should be in a mostly-banned.h, but we only have
the blanket banned.h, and there's a few legitimate uses of it :)

(And yes, this is all probably commentary on my own bugs in some WIP
code, but at this point I honestly can't remember & didn't look it up)

Thanks for hacking on this & carrying it forward!

  parent reply	other threads:[~2022-03-07 12:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 21:37 [PATCH] cat-file: skip expanding default format John Cai via GitGitGadget
2022-03-07  5:56 ` Junio C Hamano
2022-03-07  6:11   ` Junio C Hamano
2022-03-07 17:41     ` John Cai
2022-03-07 12:15 ` Ævar Arnfjörð Bjarmason [this message]
2022-03-08  2:54 ` [PATCH v2] " John Cai via GitGitGadget
2022-03-08 16:59   ` Junio C Hamano
2022-03-08 19:01     ` John Cai
2022-03-08 22:00   ` Taylor Blau
2022-03-08 22:06     ` John Cai
2022-03-08 22:24     ` Taylor Blau
2022-03-08 22:45       ` John Cai
2022-03-08 22:08   ` [PATCH v3] " John Cai via GitGitGadget
2022-03-08 22:30     ` Taylor Blau
2022-03-08 23:09       ` John Cai
2022-03-08 23:34         ` John Cai
2022-03-15  2:40     ` [PATCH v4] " John Cai via GitGitGadget

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=220307.865yoq0x7e.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johncai86@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 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).