Re: [PATCH v8 1/4] sha1_file.c: support reading from a loose object of unknown type

Jeff King [off-list ref] writes:

If there _is_ a performance implication to worry about here, I think it
would be that we are doing an extra malloc/free.

Thanks for reminding me; yes, that also worried me.

I'm not sure I
understand why we are copying it at all. The original code copied from
the hdr into type[10] so that we could NUL-terminate it, which was
required for type_from_string().

Sounds like a good plan.

But now we use type_from_string_gently, which can accept a length[1]. So
we could just count the bytes to the first space and pass the original
buffer along with that length, no?

-Peff

[1] Not related to your patch, but it looks like type_from_string_gently
    is overly lax. It does a strncmp() with the length of the candidate
    name, but does not check that we consumed all of the matching name.
    So "tr" would match "tree", "comm" would match "commit", and so
    forth.

On Fri, Apr 17, 2015 at 09:21:31AM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

If there _is_ a performance implication to worry about here, I think it
would be that we are doing an extra malloc/free.

Thanks for reminding me; yes, that also worried me.

As an aside, I worried about the extra allocation for reading the header
in the first place. But it looks like we only do this on the --literally
code path (and otherwise use the normal unpack_sha1_header).  Still, I
wonder if we could make this work automagically.  That is, speculatively
unpack the first N bytes, assuming we hit the end-of-header. If not,
then go to a strbuf as the slow path. Then it would be fine to cover all
cases; the normal ones would be fast, and only ridiculous things would
incur the extra allocation.

-Peff