Re: [PATCH v2] cat-file: skip expanding default format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Taylor,

On 8 Mar 2022, at 17:24, Taylor Blau wrote:

> On Tue, Mar 08, 2022 at 05:00:53PM -0500, Taylor Blau wrote:
>> On my copy of git.git., it shaves off around ~7ms that we're spending
>> just copying type names back and forth.
>
> ...while we're at it, I think we could go a little further and avoid
> doing the mark_query phase altogether, by doing something like:
>
> --- 8< ---
>
> diff --git a/builtin/cat-file.c b/builtin/cat-file.c
> index ab9a49e13a..4b3cfb9e68 100644
> --- a/builtin/cat-file.c
> +++ b/builtin/cat-file.c
> @@ -542,24 +542,30 @@ static int batch_objects(struct batch_options *opt)
>  	int save_warning;
>  	int retval = 0;
>
> -	/*
> -	 * Expand once with our special mark_query flag, which will prime the
> -	 * object_info to be handed to oid_object_info_extended for each
> -	 * object.
> -	 */
> -	memset(&data, 0, sizeof(data));
> -	data.mark_query = 1;
> -	strbuf_expand(&output,
> -		      opt->format ? opt->format : DEFAULT_FORMAT,
> -		      expand_format,
> -		      &data);
> -	data.mark_query = 0;
> -	strbuf_release(&output);
>  	if (opt->cmdmode)
>  		data.split_on_whitespace = 1;
>
> -	if (opt->format && !strcmp(opt->format, DEFAULT_FORMAT))
> +	memset(&data, 0, sizeof(data));
> +	if (!opt->format || !strcmp(opt->format, DEFAULT_FORMAT)) {
> +		data.info.sizep = &data.size;
> +		data.info.typep = &data.type;
> +
>  		opt->format = NULL;
> +	} else {
> +		/*
> +		 * Expand once with our special mark_query flag, which will prime the
> +		 * object_info to be handed to oid_object_info_extended for each
> +		 * object.
> +		 */
> +		data.mark_query = 1;
> +		strbuf_expand(&output,
> +			      opt->format ? opt->format : DEFAULT_FORMAT,
> +			      expand_format,
> +			      &data);
> +		data.mark_query = 0;
> +		strbuf_release(&output);
> +	}
> +
>  	/*
>  	 * If we are printing out the object, then always fill in the type,
>  	 * since we will want to decide whether or not to stream.
>
> --- >8 ---
>
> ...but in my experiments it doesn't seem to help much. Or, at least, it
> doesn't obviously help, there's too much noise from run to run for me to
> see a worthwhile speed-up here.

Yeah I had the same thought. I also didn't see a noticeable difference so I'm on the fence
regarding whether or not it's worth it. I'm kind of leaning towards no, since it adds some
one-off logic without a clear performance gain.

>
> Thanks,
> Taylor



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux