On Wed, Jan 17, 2018 at 9:37 PM, Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> wrote:
>
>
> On 1/17/2018 12:54 PM, Christian Couder wrote:
>>
>> As sha1_file_name() could be performance sensitive, let's
>> try to make it faster by seeding the initial buffer size
>> to avoid any need to realloc and by using strbuf_addstr()
>> and strbuf_addc() instead of strbuf_addf().
>>
>> Helped-by: Derrick Stolee <stolee@xxxxxxxxx>
>> Helped-by: Jeff Hostetler <git@xxxxxxxxxxxxxxxxx>
>> Signed-off-by: Christian Couder <chriscool@xxxxxxxxxxxxx>
>> ---
>> sha1_file.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/sha1_file.c b/sha1_file.c
>> index f66c21b2da..1a94716962 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -323,8 +323,14 @@ static void fill_sha1_path(struct strbuf *buf, const
>> unsigned char *sha1)
>> void sha1_file_name(struct strbuf *buf, const unsigned char *sha1)
>> {
>> - strbuf_addf(buf, "%s/", get_object_directory());
>> + const char *obj_dir = get_object_directory();
>> + size_t extra = strlen(obj_dir) + 1 + GIT_MAX_HEXSZ;
>
> Very minor nit. Should this be "+3" rather than "+1"?
> One for the slash after obj_dir, one for the slash between
> "xx/y[38]", and one for the trailing NUL.
I think the trailing NUL is handled by strbuf_grow(), but I forgot
about the / between "xx/y[38]", so I think it should be "+2" .
Anyway I agree with Junio that using strbuf_grow() is not really needed.
>> + if (extra > strbuf_avail(buf))
>> + strbuf_grow(buf, extra);
>> +
>> + strbuf_addstr(buf, obj_dir);
>> + strbuf_addch(buf, '/');
>> fill_sha1_path(buf, sha1);
>> }
